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Informationserzeuqunqssystem fur die Produktentstehung 



Die Erfindung betrifft ein System sowie ein Inf ormationsmo- 
dell zur Erzeugung von Inf ormationen iiber Datenobj ekte^ die 
jeweils einen Bestandteil eines technischen Produkts oder ei- 
nen Schritt eines Entstehungsprozesses fiir das Produkt repra- 
sentieren. 

Unter dem Begriff ProduktentstehungsprozeB wird eine Abfolge 
von Phasen und Aktivitaten verstanden, die zur Herstellung 
eines technischen Produkts notig sind. Zu diesen Phasen zah- 
len z. B. die Konstruktion und die Produktionsplanung . Die 
Aktivitaten einer Phase benotigen Zwischen- oder Endergebnis- 
se von friiheren Phasen. Moglich ist es manchmal, mehrere Pha- 
sen parallel auszufiihren. 

Die raeisten oder gar alle Phasen des Produktentstehungspro- 
zesses z. B. fur eine Automobil-Baureihe werden heutzutage 
durch den Einsatz von Modellen und automatisch auswertbaren 
Inf ormationen auf Datenverarbeitungsanlagen unterstiitzt. Ein 
Modell ist ein vereinf achtes und zwangslaufig luckenhaftes 
Abbild eines Ausschnitts der Realitat, hier des Produkts oder 
des Produktentstehungsprozesses, auf einer Datenverarbei- 
tungsanlage. Das Modell enthSlt die Eigenschaf ten und AbhSn- 
gigkeiten der Realitat, die zur Losung einer bestimmten Auf- 
gabe einer Phase benotigt werden. Mit dem Begriff ^^Informati- 
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on^^ wird der abstrakte Bedeutungsinhalt (die „Semantik^' ) ei- 
ner Aussage, Beschreibung, Anweisung^ Nachricht Oder Mittei- 
lung bezeichnet. Um Inf ormationen z. B- in einem Rechner zu 
reprasentieren und abzuspeichern warden Daten verwendet. Ein 
5 Inf ormationsmodell ist eine Vereinf achung der Realitat^. durch 
die Inf ormationen und Fakten ftir die Bearbeitung mindestens 
einer Aufgabe strukturiert werden. Ein Datenmodell be- 
schreibt;. wie die gemaB eines Inf ormationsmodells struktu- 
rierten Daten physikalisch gespeichert werden, z. B. in einer 
10 Datei oder einer Datenbank. 

Weil oft in jeder Phase spezifische Anf orderungen zu erfiillen 
sind und diese Anf orderungen von Phase zu Phase differieren 
und weil fiir die Erfiillung dieser Anf orderungen z. T. spezi- 
fische Inf ormationen benotigt werden^. wird in jeder Phase ei- 
15 ne spezifische Sicht auf das zu entwickelnde und zu fertigen- 
de technische Produkt benotigt. Gewtinscht werden Ansatze, 
welche die Modelle und Inf ormationen der verschiedenen Phasen 
so verkntipfeni. dafi die spezifischen Anf orderungen jeder Phase 
erfullt werden und dennoch die Modelle widerspruchsf rei zu- 
20 einander sind und moglichst keine Redundanzen, also mehrfache 
identische Inf ormationen, aufweisen. Anderungen an einem Mo- 
dell einer Phase werden idealerweise in Modellen anderer Pha- 
se nachgeftihrt. 

Moderne Werkzeuge ftir den rechneruntersttitzten Entwurf (com- 
^25 puter-aided design, CAD) bieten die MSglichkeit, Konstrukti- 
ons-Gestaltungselemente (design features) oder allgemeiner 
Gestaltungselemente (features) , auch Funktionselemente ge- 
nannt, als Bestandteile von Produktmodellen zu definieren. 
Ein Konstruktions-Gestaltungselement reprasentiert eine Kom- 
30 ponente eines Bauteils und enthSlt geometrische Festlegungen, 
z. B. Oberflachen, Kanten, geometrische Korper, Abrundungen. 
Bohrungen, Taschen, Nuten und Rippen an Zylinderkopfen von 
Automobil-Motoren sind Beispiele ftir Konstruktions- 
Gestaltungselemente. Gestaltungselemente sind durch den Vor- 
35 schlag ftir die Deutsche Norm DIN 32869-3 ,,Technische Produkt- 



# 

3 

dokumentation - Dreidimensionale CAD-Modelle - Teil 3: Funk- 
tionselemente^^ vom Februar 2002 bekannt. 

CAD-Werkzeuge, z. B. CATIA Oder UniGraphics oder ProEngineer, 
bieten oft eine Bibliothek mit Typen von Gestaltungselementen 
sowie Funktionalitaten, mit denen ein Benutzer eigene Typen 
von Gestaltungselementen (user-defined feature types) erzeu- 
gen kann. Oft sind die Gestaltungselemente auf die spezifi- 
schen Anf orderungen und die Begriffswelt einer Phase zuge- 
schnitten. Sie sind die kleinsten Bausteine (building blocks) 
mit funktionaler Bedeutung, mit denen ein Benutzer ein Pro- 
dukt-Modell fur eine Phase aufbaut und damit eine spezifische 
Sicht auf das Produkt realisiert. Gestaltungselemente repra- 
sentieren z. B. Bohrungen und Ausf rasungen^ ihnen lassen sich 
Attribute mit einer Semantik fur die Konstruktion oder Ferti- 
gung zuordnen. Geometrische Grundelemente, z. B. Linien^ 
Kreise und Quader, sind ebenfalls Bausteine^ die in vielen 
Produkt-Modellen verwendet werden, aber keine funktionale Be- 
deutung besitzen. 

Aus T, N. Wong und C. B. Leung: „An object-oriented neutral 
feature model for feature mapping'^ Internat. Journal of Pro- 
duction Research, Vol.38 (2000), pp. 3573 - 3601, sind Taxo- 
nomien (Verwandtschaf tshierarchien) unter Typen von Gestal- 
tungselementen bekannt- Eine Taxonomie bezieht sich. bei Wong 
und Leung auf Gestaltungselemente einer Phase. Das Konzept 
von Typen und Exemplaren von Gestaltungselementen entspricht 
dem von Klassen und Objekten (classes and instances, classes 
and objects) der objekt-orientierten Programmierung. In einer 
Taxonomie ist festgelegt, daJi ein Typ A ein Obertyp eines 
Typs B ist, Alle Eigenschaf ten des Typs A gelten auch ftir den 
Typ B und damit fur alle Gestaltungselemente. 

Um Modelle fUr verschiedene Phasen des Produktentstehungspro- 
zesses zu verkntipfen, wurden verschiedene Ansatze der Gestal- 
tungslemente-Transformation (feature mapping, feature conver- 
sion, feature transformation) vorgeschlagen. Die dahinterlie- 
gende Idee ist die: Gegeben ist eine Menge A von Gestaltungs- 
elementen ftir eine erste Phase. Durch Anwendung einer Trans- 
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formation auf die Menge A wird eine Menge B von Gestaltungs- 
elementen fur eine zweite Phase erzeugt. Im allgemeinen Fall 
werden hierbei n Gestaltungselemente der Menge A auf m Ges- 
taltungselemente der Menge B abgebildet, also wird eine n:in- 
Abbildung ausgefiihrt. 

Aus F.-L. Krause^ S- Kramer, E. Rieger: „PDGL - a Language 
for Efficient Feature-Based Product Gestaltung'^ , Annals of 
the CIRP, Vol. 40 No. 1 (1991), pp. 135 - 138, sowie aus F.- 
L- Krause^ A. Ulbrich, F. H. Vosgerau: „Feature-Based Appro- 
ach for the Integration of Design and Process Planning Sys- 
tems'", In: J- P. A. M. W. J. Turner (ed. ) , Proceedings of the 
23rd International Symposium on Automotive Technology & Auto- 
mation, Wien, Dec. 1990, pp. 140 - 147, ist eine Vorgehens- 
weise bekannt, durch die den Typen von Gestaltungselementen 
Wissen Ober und Vorschriften fur die Transformation von Ges- 
taltungselementen (feature mapping knowledge) zugeordnet werr- 
den. In den Druckschrif ten wird eine formale Sprache namens 
„Part Design Graph Language"" (PDGL) zur Reprasentation der 
Vorschriften offenbart. Die in PDGL formulierten Vorschriften 
werden z. B. von einem Interpreter der formalen Sprache abge- 
arbeitet. In J. J. Shah, D. Hsiao, J. Leonard: „A Systematic 
Approach for Design-Manufacturing Feature Mapping^", in P.R. 
Wilson, M,J. Wozny, M.J. Pratt (eds.): ^Geometric Modeling 
for Product Realization"", North-Holland Publ.,. 1992, pp. 205 
- 221, werden automatisch ausfuhrbare Vorschriften direkt 
mittels einer Programmiersprache implementiert , und zwar als 
Teil der Verarbeitungs-Algorithmen eines Werkzeugs zum Pro- 
duktentwurf . Die Vorschriften legen fest, wie Typen benutzer- 
definierter Konstruktions-Gestaltungselemente (user defined 
design features) auf vorab definierte und in einer Bibliothek 
abgespeicherten Typen von Bearbeitungs-Gestaltungselemente 
(manufacturing features) abgebildet werden. Diese Abbildung 
wird mittels eines Rekonstruktions-Algorithmus, der die oben 
skiz-zierte Transformation realisiert, durchgefahrt Der Algo- 
rithmus lief ert einen „Constructive Feature Tree"" . 



In Y. S. Suh, M. J. Wozny: Interactive Feature Extraction for 
a Form Feature Mapping System^" ^ Rensselaer Polytechnic Insti- 
tute Troy, New York, 1998, und in T- N. Wong und C. B. Leung, 
a.a.O., werden Ansatze zur Transformation von Gestaltungsele- 
menten vorgestellt, die auf einem Zwischenmodell fur die Pro- 
d^kt-Geometrie beruhen. Dieses Zwischenmodell enthalt anwen- 
dungsneutrale Typen und Exemplare von Zwischen- 
Gestaltungselementen. Die Transformation wird indirekt ttber 
das Zwischenmodell durchgef iihrt . In W. F. Bronsvoort, 
A. Noort, J- van den Berg und G. F, M, Hoek: „Product deve- 
lopment with multiple-view feature modelling^". Proceed FEATS 
2001, und in K. J. De Kraker: „Feature Mapping for Concurrent 
Engineering'', Promotionsschrif t. Delft University of Techno- 
logy, 1997, wird jeweils ein ftir eine bestimmte Phase erzeug- 
tes und dort verwendetes Produktmodell als zentrales Zwi- 
schenmodell benutzt, namlich das Produktmodell fiir die Phase 
Konstruktion (design feature model) . In beiden Druckschrif ten 
werden Gestaltungselemente in zwei Schritten automatisch aus 
der Bauteil-Geometrie identif iziert (feature recognition) , urn 
aus den Konstruktions-Gestaltungselementen (design features) 
Gestaltungselemente fiir andere Phasen zu erzeugen. Anderungen 
in anderen Phasen werden in beschranktem Umfang erkannt und 
fuhren automatisch zu entsprechenden Anderungen am Zwischen- 
modell. In Wong, a.a.O., werden aus Gestaltungselementen des 
neutralen Zwischenmodells anwendungsspezif ische Gestaltungs- 
elemente erzeugt. Hierfur werden regelbasierte Systeme ange- 
wendet, wie sie aus der ^ktinstlichen Intelligenz'' bekannt 
sind. 

Ein grundlegender Nachteil von Zwischenmodellen ist der, daJi 
sich nur diejenigen Sachverhalte in einem phasenspezif ischen 
Modell beschreiben lassen, die sich auch im Zwischenmodell 
ausdrucken lassen. Daher mufl das Zwischenmodell jede Informa- 
tion abspeichern, die in irgendeiner Phase benotigt wird. Da- 
her umfalit das Zwischenmodell oft schwer zu handhabende Typen 
von „Allzweck-Gestaltungselementen'' , eine Speicherung ftihrt 
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zu unerwunscht redundanter Datenhaltung und erfordert hohen 
Speicherplat zbedarf . 

Aus EP 785491 A2 sind ein Verfahren und eine Vorrichtung be- 
kannt, iim Inf ormationen uber die Konstruktion und Informatio- 
5 nen uber die Produktion miteinander zu verkniipfen und zu ver- 
walten- Zwischen verschiedenen Inf ormationen werden Relatio- 
nen hergestellt und verwendet, urn von einer Gruppe von Inf or- 
mationen zu einer anderen Gruppe zu gelangen. Die Inf ormatio- 
nen z. B. iiber Produkte, Bauteile und Feirtigungsschritte 
10 (processes) werden durch Datensatze gespeichert, die Relatio- 
nen durch Verweise zwischen Datensatzen. Ein Datenbankschema 
wird erzeugt^ durch das Datensatze in sinnvollen Beziehungen 
zueinander strukturiert und abgespeichert werden. Automat isch 
auswertbare Vorschriften werden in EP 785491 A2 nicht er- 
15 wShnt. 

Der Erfindung liegt die Aufgabe zugrunde, ein System nach dem 
Oberbegriff des Anspruchs 1 und ein Inf ormationsmodell nach 
dem Oberbegriff des Anspruchs 13 zu schaffen^ die kein Zwi- 
schenmodell erfordern und durch die sich die automatisch aus- 
20 wertbaren Vorschriften fur Abhangigkeiten zwischen Datenob- 
jekten effizient und ohne Redundanz aufstellen, erweitern, 
andern^ speichern und ISschen lassen. 

Die Aufgabe wird durch ein System nach Anspruch 1 und durch 

ein Inf ormationsmodell nach Anspruch 13 gelost. Vorteilhafte 

25 Ausgestaltungen sind in den Unteransprtlchen angegeben. 

» 

Erf indungsgemali werden neben den Datenobj ekten, die Bestand- 
teile des Produkts oder Prozesses reprasentieren,. weitere Da- 
tenobjekte vorgesehen, namlich Relationen zwischen Datenob-- 
jekten und Typen derartiger Relationen. Dadurch^ daJ5 die Ab- 

30 hangigkeiten zwischen Datenob jekten als spezielle, ebenfalls 
typisierbare Datenob jekte behandelt werden^ wird eine modula- 
re Datenhaltung erreicht und unerwunschte Redundanz in der 
Datenhaltung reduziert. Insbesondere die modulare Datenhal- 
tung fUhrt dazu, dafi sich die Vorschriften leicht aufstellen, 

35 erweitern, andern und 16schen lassen- 
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Datenobjekte fur verschiedene Phasen oder von verschiedenen 
Anwendungen werden durch derartige Relationen verkntipft. Ins- 
besondere verbinden diese Relationen solche Datenobjekte, die 
dasselbe Bestandteil des Produkts oder Prozesses fiir ver- 
5 schiedene Phasen reprasentieren. Dank der Relationen laiJt 
sich automatisch und effizient ermitteln, welche Datenobjekte 
sich auf dasselbe Bestandteil beziehen und welche weiteren 
Datenobjekte nach Anderung eines ersten Datenobjekts verSn- 
dert werden mtissen^ damit alle Datenobjekte far ein Bestand- 
10 teil zueinander konsistent bleiben. Damit reduziert die Er- 
findung die Anzahl und die Schwere von Fehlern im Produk- 
tentstehungsprozeJJ, insbesondere die solcher Fehler, die auf 
Widerspriichen zwischen den verschiedenen Produkt- oder Pro- 
zeBmodellen beruhen. Anderungen an einzelnen Modellen werden 
15 vereinfacht^ well die automatisch ausfUhrbaren Vorschrif ten,, 
welche die Konsequenzen der Anderungen ermitteln und/oder au- 
tomatisch ausfuhren;. effizient und ohne Redundanz aufstell- 
bar^ erweiterbar^ anderbar, speicherbar und 15schbar sind. 

Die Relationen sind in Typen klassif izierbar . Dadurch brau- 
20 Chen Inf ormationen, die fiir n ahnliche Relationen Rel_l, . . . 
^ Rel_n zwischen Datenobjekten gtiltig sind, riicht mehrfach 
formuliert und abgespeichert zu werden. Beispiele fur derar- 
tige Inf ormationen sind automatisch auswertbare Vorschrif ten. 
Attribute, zulassige Wertebereiche, Vorzugswerte oder Stan- 
^25 dardwerte (default values) sowie Abhangigkeiten (constraints) 
und Berechnungsvorschriften zwischen Attributen von durch ei- 
ne Relation verbundenen Datenobjekt-Typen. Vielmehr wird ein 
Typ von Relationen erzeugt, und festgelegt wird, dafi Rel_l, 
... , Rel_n alle von diesem Typ sind. Die Inf ormationen wer- 
30 den dem Typ zugeordnet und brauchen nur einmal erzeugt und 
abgespeichert zu werden. Sie sind damit fUr Rel^l^ ... , 
Rel_n gtiltig. 

Nicht jedes Datenobjekt und jede Relation ist notwendigerwei- 
se einem Datenobj ekt-Typ bzw. Relations-Typ zugeordnet. Die- 
35 jenigen Datenobjekte und Relationen, die einem Typ zugeordnet 
sind, werden als „typisiert^' bezeichnet. 
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Die Einfuhrung von Relations-Typen erlaubt einen einfachen 
und einheitlichen Zugriff auf alle Relationen eines Relati- 
ons-Typs, Beispielsweise kann eine Anwendung des Produktent- 
stehungsprozesses alien Relationen ein neues Attribut zuord- 
5 nen oder Auswertungen uber diejenigen Attributwerte machen^ 
die die Relationen eines Typs annehmen. Die Anwendung braucht 
nicht den jeweiligen Namen der Relationen oder eine Kennung 
(identifier) oder einen Zugriffspfad auf die Relationen des 
Typs zu kennen, lam den Zugriff durchzufiihren. Weiterhin er- 
10 leichtert die Einftihrung von Relations-Typen die Filterung 
bestimmter Relationen erheblich, weil z. B. lediglich be- 
stimmte Relations-Typen vorgegeben zu werden brauchen und al- 
le Relationen dieser vorgegebenen Relations-Typen herausge- 
filtert werden. Diese Filterung erleichtert das Wiederauf f in- 
15 den von Inf ormationen^ was zu geringeren Rechenzeiten fiihrt 
und die Arbeit von Fachexperten erleichtert. 

Die automatisch auswertbaren Vorschriften werden diesen Rela- 
tions-Typen zugeordnet und nicht z. B. einzelnen Relationen 
Oder gar Typen von Kdnstruktions-Gestaltungselementen (design 
20 features) . Dadurch bleiben Datenobjekt-Typen frei von Verwei- 
sen auf andere Datenobjekt-Typen, was unvermeidlich ware, 
wenn die automatisch auswertbaren Vorschriften Datenobjekt- 
Typen zugeordnet werden wiirden. Dieses Merkmal ist insbeson- 

•dere dann von Vorteil, wenn ein anderer Datenobjekt-Typ, auf 
25 den ein erster Datenobjekt-Typ verweist, geloscht wird. Wenn 
der erste Datenobjekt-Typ einen Verweis auf den anderen Da- 
tenobjekt-Typ hatte, muBte sichergestellt werden, daJ5 dieser 
Verweis beim Loschen des anderen Datenobjekt-Typs geloscht 
wird. Durch die Erfindung werden Datenobjekte getrennt von 
30 ihren wechselseitigen Beziehungen erzeugt und abgespeichert . 

Das erf indungsgemafie System benotigt kein Zwischenmodell, das 
fiir mehrere Phasen des Produktentstehungsprozesses gultig 
ist. Dadurch vermeidet das System die oben beschriebenen 
Nachteile. 

35 Die groBe Komplexitat aufgrund der vielen verschiedenen Da- 
tenobjekte far die Phasen wird beherrschbar gemacht. 
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Vorzugsweise werden die automatisch auswertbaren Vorschriften 
so formuliert^ dali sie nicht von einer bestiinmten Anwendung 
des Produktentstehungsprozesses abhangen, sondern anwendungs- 
neutral sind- Dadurch laJit sich eine zusatzliche Anwendung 
erganzen oder eine alte durch eine neue ersetzen, ohne die 
Datenhaltung anderer Anwendungen Sndern zu miissen. Die Vor- 
schriften reprSsentieren Inf ormationen daruber^ welche Be- 
rechnungen^ Auswertungen und Generierungen durchzuf uhren 
sind. Inf ormationen, wie die Vorschriften im einzelnen auszu- 
f uhren sind, werden der jeweiligen ausfuhrenden Anwendung zu- 
geordnet . 

Weil automatisch auswertbare Vorschriften den Relations-Typen 
zugeordnet werden, lassen die Vorschriften sich andern, ohne 
Typen von Datenobjekten verandern zu miissen. Die Vorschriften 
werden direkt den Typen derjenigen Datenobjekte zugeordnet/ 
auf die sie sich beziehen, namlich Typen von Relationen zwi- 
schen Datenobjekten. Vermieden wird die Notwendigkeit , eine 
komplexe unstrukturierte Wissensbasis flir viele verschiedene 
Vorschriften aufzustellen. Eine solche Wissensbasis ist nur 
schwer zu warten. Die Gefahr ist groB, daB sich unentdeckte 
Fehler in eine solche Wissensbasis einschleichen und zu feh- 
lerhaften Produktentwtirf en oder gar fehlerhaften Produkten 
f tihren. 

Ein weiterer Vorzug der Erfindung ist der, daB sie bereits 
dann produktive Ergebnisse liefern kann, wenn noch nicht alle 
Datenobjekt-Typen durch Relations-Typen miteinander verbunden 
sind. Vielmehr kann das erf indungsgemaBe System auch mit un- 
vollstandigen Inf ormationen arbeiten, z. B. mit Relations- 
Typen fur nur einige der AbhSngigkeiten zwischen Datenobjekt- 
Typen. Spatere ErgSnzungen machen es nicht erf orderlich, fru- 
here Festlegungen nachtraglich zu Qberarbeiten. Dieser Aspekt 
ist insbesondere dann wichtig, wenn der Produktentste- 
hungsprozeB in einem Unternehmen bereits etabliert ist, spe- 
zifische Anwendungen fUr einzelne Phasen im produktiven Ein- 
satz sind und daher das erf indungsgemaBe System bei seiner 
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Einfiihrung schrittweise mit den bestehenden produktiv genutz- 
ten Anwendungen gekoppelt wird, well es unmoglich ist, es im 
laufenden Betrieb schlagartig mit alien diesen Anwendungen zu 
kombinieren oder gar den laufenden Betrieb fur die Einfiihrung 
5 zu unterbrechen. Unterschiedliche Grade der Kopplung ver- 
schiedener Anwendungen sind mittels des erf indungsgemaJien 
Systems realisierbar . Das erf indungsgemafie System kann zu- 
nSchst prototypisch fur einzelne Phasen und Anwendungen ein- 
gesetzt warden und schrittweise mit weiteren Anwendungen ge- 
10 koppelt werden. Vor allem diese Skalierbarkeit ermOglicht es, 
das erf indungsgemalJe System evolutionSr in einen bestehenden 

•ProduktentstehungsprozeB einzufiihren. Der oben genannte As- 
pekt ermoglicht es dariiber hinaus, die Erfindung im Verlaufe 
eines Produktentstehungsprozesses anzupassen, anstelle wfih- 
15 rend des gesamten Produktentstehungsprozesses mit einem star- 
ren Datenhaltungs schema auskommen zu mussen. 

Die Einftihrung von Relations-Typ-Kategorien unter Relations- 
Typen ist ein weiteres Merkmal, durch welches doppelte und 
unerwiinscht redundante Datenhaltung vermieden wird. Informa- 
2u tionen, die ftir m Relations-Typen T_l, ... , T_m gultig sind, 
werden einer Relations-Typ-Kategorie K zugeordnet. Die Infor- 
mationen werden einmal formuliert und abgespeichert . Bei der 
Erzeugung der m Relations-Typen T_l, ... , T_m wird vorgege- 

• ben, dali diese m Typen von der Relations-Typ-Kategorie K 
5 sind. Dadurch sind die Festlegungen fiir K fur die m Relati- 
ons-Typen gultig. MSglich ist auch;. einen Relations-Typ T_i 
nachtraglich einer Relations-Typ-Kategorie zuzuordnen . 

Insbesondere laBt sich fiir eine Relations-Typ-Kategorie fest- 
legen, welche Attribute und Methoden die Relations-Typen der 

30 Kategorie haben mussen. Weitere Beispiele fiir Inf ormationen^ 
die einer Relations-Typ-Kategorie zugeordnet sind, sind die 
Festlegungen, daJ5 jeder Relations-Typ der Kategorie einen Na- 
men und eine automatisch auswertbare Vorschrift besitzen muJ5. 
Verarbeitungs-Algorithmen lassen sich ebenfalls einer Katego- 

35 rie zuordnen. Ftir eine Relations-Typ-Kategorie kann eine Vor- 
schrift festgelegt sein, welche die Zuordnung von Datenob- 
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jekt-Typen an Relations-Typen der Kategorie einschrankt oder 
liberpruft. Diese Vorschrift niirant B. Bezug auf Datenob- 

jekt-Typen. Moglich ist auch^ Kategorien von Datenobj ekten 
einzufiihren und in einer Vorschrift^ die einer Relations-Typ- 
Kategorie zugeordnet ist, Bezug auf Datenobj ekt-Kategorien zu 
nehrtien . 

Ein weiterer Vorteil der Verwendung von Relations-Typ- 
Kategorien tritt auf, wenn Inf ormationen, die fur itiehrere Re- 
lations-Typen der gleichen Relations-Typ-Kategorie giiltig 
sind, nachtraglich geandert werden miissen, z. B. aufgrund ei- 
nes neuen Konstruktionsstandes, neuer Anf orderungen an das zu 
entwerfende und zu fertigende Produkt oder weil Fehler im al- 
ten Entwurf oder Arbeit splan offenbar wurden. Weil die Infor- 
mationen nur einmal abgespeichert sind, namlich als Teil der 
Informationen Ober eine Relations-Typ-Kategorie, brauchen sie 
nur einmal geandert zu werden. Waren sie hingegen mehrfach 
und redundant abgespeichert, miifiten mehrere AnderungsvorgSnge 
durchgefiihrt werden. Die Gefahr ist groJJ, daJJ ein erforderli- 
cher Anderungsvorgang gar nicht oder nur unvollstandig oder 
fehlerhaft ausgefUhrt wird und dadurch Fehler in das Produkt- 
modell geraten. 

Bestimmte Relations-Typen lassen sich dadurch automatisch 
auswahlen, dafi mindestens eine bestimmte Relations-Typ- 
Kategorie vorgegeben wird, wodurch alle Relations-Typen der 
vorgegebenen Kategorie ausgewahlt sind. Dadurch ist eine in- 
telligente Filterung von und eine Fokussierung auf bestimmte 
Relations-Typen moglich. 

Die Taxonomie unter Relations-Typ-Kategorien ordnet die u. U. 
umfangreiche Menge von Relations-Typen. Eine Anwendung kann 
automatisch syntaktische Regeln und eine Semantik fUr einen 
Relations-Typ ermitteln, indem sie die zugeordnete Relations- 
Typ-Kategorie und ihre Position in der Taxonomie ermittelt 
und die Informationen tiber diese Relations-Typ-Kategorie aus- 
wertet. Die Gefahr wird reduziert, dali verschiedene Relati- 
ons-Typen fur denselben Sachverhalt eingeftihrt werden. Da- 
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durch werden unerwunschte Redundanz und Uberschneidungen ver- 
mieden . 

Vorzugsweise wird eine einheitliche Taxonomie unter alien Ty- 
pen von Datenobjekten aufgestellt. Diese Taxonomie lamfaBt 
mehrere Phasen des Produktentstehungsprozesses sowie Datenob- 
jekt-Typen fur unterschiedliche Abstraktionsebenen des Pro- 
dukts^ also z. B, Zusammenbauten^ Bauteile, Konstruktions- 
Gestaltungselemente und Fertigungs-Gestaltungselemente in ei- 
ner einzigen Taxonomie. Insbesondere ist die Taxonomie nicht 
auf Typen von Gestaltungselementen beschrankt. Dadurch lassen 
sich verschiedene Phasen und Abstraktionsebenen einheitlich 
und mit gleicher Notation behandeln. 

Bevorzugt werden die Taxonomie unter Relations-Typ-Kategorien 
und die Taxonomie unter Datenobjekt-Typen nicht fur jeden 
Produktentstehungsprozefi erneut erzeugt. Vielmehr umfaJit das 
erf indungsgemafie System zwei anwendungsiibergreif ende und vor- 
ab definierte und erweiterbare Standard-Bibliotheken, namlich 
eine mit Datenobjekt -Typen und eine weitere mit Kategorien 
von Relations-Typen zwischen diesen Datenobjekt-Typen. Diese 
beiden Standard- Bibliotheken sind z. B. fiir jede Baureihe 
eines Automobilherstellers, die gemaJJ einem einmal definier- 
ten Produktentstehungsprozefi entworfen und hergestellt wird,r 
gaitig. Sie lassen sich als Ausgangspunkt far einen bestiiran- 
ten Produktentstehungsprozefi^ beispielsweise eine bestimmte 
neue Baureihe eines Automobilherstellers^ verwenden und er- 
weitern^ z. B, ftir den' Produktentstehungsprozefi einer be- 
stimmten Baureihe oder eine bestimmte Anwendung. Vorzugsweise 
haben die Bibliotheken datentechnisch die Form von einbindba- 
ren Sof tware-Bibliotheken (libraries) oder von Datensatzen in 
einer Datenbank. Moglich ist auch^ nur die Standard- 
Bibliothek fur Datenobjekt-Typen oder nur das fur Relations- 
Typen vorzusehen. 

Spezif ische Da t enob j ekt -Typen und Relations-Typ-Kategorien 
werden als Untertypen von Datenobjekt-Typen bzw. Relations- 
Typ-Kategorien der Standard-Bibliotheken erzeugt. Attribute 
und sonstige Inf ormationen, die einem Datenobjekt-Typ bzw. 
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eine Relations-Typ-Kategorie der jeweiligen Standard- 
Biblibthek zugeordnet sind, sind durch Vererbung entlang der 
Taxonomie der Datenobjekt-Typen bzw. der Relations-Typ- 
Kategorien auch fur alle Untertypen gultig - es sei denn, fur 
den Datenobjekt-Typ bzw. die Relations-Typ-Kategorie festge- 
legt, Festlegungen fur einen spezif ischeren Datenobjekt-Typ 
liberschreiben geerbte Festlegungen fiir einen abstrakteren Da- 
tenobjekt-Typen (overloading) . Spezif ische Typen und Katego- 
rien besitzen dadurch, dafi sie als Untertypen bzw. Unterkate- 
gorien von Typen bzw. Kategorien einer anwendungstibergreif en- 
den Standard-Bibliothek erzeugt wurde^ bereits durch die Er- 
zeugung eine grobe Semantik und kOnnen von Anwendungen ausge- 
wertet werden. Beispielsweise kann eine Vorschrift^ die auf 
einen Typ oder eine Relation einer Standard-Bibliothek Bezug 
nimmt^ auch auf den spezif ischen Untertyp bzw. auf die Unter- 
kategorie angewendet werden. Denn der Untertyp bzw. die Un- 
terkategorie besitzt durch Vererbung mindestens alle diejeni- 
gen Vorschriften, Methoden, Attribute etc., die dem Typ bzw. 
der Kategorie aus dem Standard-Bibliothek zugeordnet sind. 

Die Taxonomie unter Datenobjekt-Typen erleichtert die Zuord- 
nung von Datenobjekt-Typen an Relations-Typen. Einem Relati- 
ons-Typ kOnnen z. B. zwei abstrakte Datenobjekt-Typen zuge- 
ordnet sein, das sind zwei Datenobjekt-Typen, die Wurzeln von 
Asten der baumartigen Taxonomie sind, also mehrere Untertypen 
haben. Durch diese Zuordnung ist festgelegt, dafi eine Relati- 
on des Relations-Typs zwei Datenobjekte von zwei Datenobjekt- 
Typen dieser beiden Aste verbinden darf, aber keine Datenob- 
jekte anderer Datenobjekt-Typen. Die Prufung wird z. B. auto- 
matisch nach der Erzeugung einer Relation durchgef uhrt . Die 
Taxonomie unter Datenobjekt-Typen kann Mehrf ach-Vererbung 
vorsehen, d. h. ein Datenobjekt-Typ kann mehrere andere Da- 
tenobjekt-Typen als Obertypen haben und von diesen verschie- 
dene Vorschrif ten, Methoden oder Attribute erben. Die Taxono- 
mie bildet dann keinen Baum mehr, sondern einen gerichteten 
azyklischen Graphen. 
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Bevorzugt wird - zusatzlich zur Verkntipfung von Datenobjekten 
durch Relationen - eine automat ische Erkennung von Gestal- 
tungselementen (feature recognition^^ feature identification) 
durchgef tihrt . Hierbei. werden bestiinmte noch nicht typisierte 
5 Bestandteile eines Produkt- oder Prozelimodells dadurch typi- 
sierte daJB sie vorab definierten Datenobjekt-Typen zugeordnet 
werden. Vorzugsweise wird ermoglicht, dafl ein Bestandteil 
nicht nur einem Blatt der Taxonomie unter Datenobjekt-Typen 
zugeordnet werden kann, sondern auch einem abstrakten Daten- 
10 objekt-Typ. AnschlieBend werden diese Datenobjekte durch Re- 
lationen mit weiteren Datenobjekten fiir andere Phasen des 
Produktentstehungsprozesses verbunden . 

Vorzugsweise werden Datenobjekt-Typen und damit Datenobjekte 
bestimmten Phasen des Produktentstehungsprozesses zugeordnet. 
15 Ein Datenobjekt-Typ kann mehreren Phasen zugeordnet sein. Die 
Phasen werden z. B. ebenfalls als Datenobjekt-Typen model- 
liert, die durch Relations-Typen mit anderen Datenobjekt- 
Typen verbunden sind, 

Das erf indungsgemafte System umfaJSt vorzugsweise (Anspruch 8) 
20 eine Einrichtung zur Zuordnung eines Datenobjekt-Typs zu min- 
destens einer von mindestens .zwei verschiedenen Phasen des 
Entstehungsprozesses und eine Einrichtung zur Erzeugung einer 

•einzigen Taxonomie far Datenobjekt-Typen, die einer 

I ersten Phase zugeordnet sind, und fiir Datenobjekt-Typen 
25 (500.1, 500.2, ...), die einer zweiten Phase zugeordnet sind. 
Die Taxonomie kann Datenobjekt-Typen ftir beliebig viele Pha- 
sen umfassen. Diese Ausgestaltung wird vorzugsweise mit einem 
System mit den Merkmalen des Anspruchs 1 kombiniert. Es ist 
aber auch moglich, ein System zur Erzeugung von Inf ormationen 
30 tiber Datenobjekte vorzusehen, wobei das System 

- eine Einrichtung zur Erzeugung von Typen von Datenobjek- 
ten, 

- eine Einrichtung zur Zuordnung eines Datenobjekt-Typs zu 
einer Phase 
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- und eine Einrichtung zur Erzeugung einer einzigen Taxono- 
mie fur Datenobjekt-Typen 

iimf afit . 

Im folgenden wird ein Ausf iihrungsbeispiel des erf indungsgema- 
lien Systems und Informationsmodells anhand der beiliegenden 
Zeichnung naher beschrieben. Dabei zeigen: 

Fig. 1. das Zusainmenspiel des erf indungsgemaBen Systems mit 
mehreren Anwendungen; 

Fig. 2. eine Architektur mit dem erf indungsgemafien System 
und mehreren Anwendungen; 

Fig. 3. einen Ausschnitt aus einer Taxonomie unter Datenob- 
jekt-Typen. 

Fig. 1 veranschaulicht fur diese Ausftihrungsf orm das Zusam- 
menspiel des erf indungsgemafien Systems mit vier Anwendungen 
200.1, 200.2, 200.3 und 200.4. Das erf indungsgemSfie System 10 
umfafit das zentrale Diensteprogramm 98 sowie die zentrale Da- 
tenbank 100 mit Relations-Typ-Kategorien, Datenobjekt- und 
Relations-Typen sowie Relationen 400.1, 400.2, 400.3, 400.4. 
Relations-Typ-Kategorien einerseits, Relations-Typen 600 und 
Datenobjekt-Typen 500 andererseits und Relationen 400 als 
Drittes bilden logisch drei unterschiedliche Abstraktionsebe- 
nen, warden aber vorzugsweise physikalisch in derselben zent- 
ralen Datenbank 100 gespeichert. Inf ormationsweiterleitungs- 
Schnittstellen 250 verbinden das zentrale Diensteprogramm 98 
mit vier Anwendungen 200.1, 200.2, 200.3 und 200.4. Die bei- 
den Anwendungen 200.2 und 200.4 verwalten je eine lokale Da~ 
tenhaltung 110.1 und 110.2, die mit Daten aus der zentralen 
Datenbank 100 geftillt wird. Alle vier Anwendungen verwalten 
spezifische Produktmodelle 150.1, 150.2, 150.3 und 150.4 mit 
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Datenobjekten 300.1, 300.2, 300.3, 300.4 und 300.5. Zwischen 
drei Datenobjekten 300.1, 300.2 und 300.5 in den Produktmo- 
dellen 150.1 und 150.3 besteht in diesem Beispiel eine Rela- 
tion 400.1, zwischen 300.2 und 300.4 in den Produktmodellen 
150.2 und 150.4 eine Relation 400.2. Die Relation 400.1 ver- 
bindet also drei Datenitiodelle miteinander, von denen zwei 
derselben Anwendung und das dritte einer anderen Anwendung 
angehoren. Diese Relationen werden in der zentralen Datenbank 
100 abgespeichert und verwaltet. Eine derartige Architektur 
wird im folgenden eingehender beschreiben. 

Das erf indungsgemalie System 10 wird mit Hilfe einer zentralen 
Datenverarbeitungsanlage realisiert, die vorzugsweise mit 
mehreren anderen Datenverarbeitungseinrichtungen verbunden 
ist. Das System 10 umfalJt ein zentrales Diensteprogramm (ap- 
plication server) 98 sowie eine zentrale Datenbank 100. Vor- 
zugsweise fungiert das erf indungsgemafie System 10 als zentra- 
les Datenhaltungssystem fUr die Anwendungen 200 und damit fOr 
mehrere Phasen des Produktentstehungsprozesses . Dadurch wird 
eine Anwendung 200 fiir eine Phase mit Oaten und Inf ormationen 
aus anderen Phasen versorgt, und die einzelnen Anwendungen 
werden besser miteinander integriert. Diese Versorgung mit 
Daten und Inf ormationen vermeidet Fehler, die z. B. aufgrund 
von Medienbruchen entstehen, spart Zeit ein und erleichtert 
Anderungen, well die Auswirkungen einer Anderung in einer 
Phase auf andere Phasen oder auf andere Anwendungen 200 er- 
mittelt werden. 

Die Anwendungen 200 lOsen in der Regel spezifische Aufgaben 
ftir bestimmte Phasen des Produktentstehungsprozesses. Zu die- 
sen Phasen zShlen z. B. Auslegung (concept design), Konstruk- 
tion (detailed design) , Berechnungen, Konstruktion der zur 
Produktfertigung benotigten Werkzeuge, Prototypenbau und Er- 
probung, Arbeitsplanung fur die Serienproduktion, Ressourcen- 
planung, Arbeitsplanung fur die Serienproduktion einschlieli- 
lich Betriebsmittelplanung, Serienproduktion, Qualitatskon- 
trolle, Auswertung von Erfahrungen im Serieneinsatz . Beispie- 
le fUr die Anwendungen 200 auf den Datenverarbeitungseinrich- 
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tungen sind Sof tware-Systeme zur Konstruktion (computer-aided 
design, CAD) , zur Produktdaten-Verwaltung (product data mana- 
gement, product engineering management) , zur Produkt simulati- 
on mittels Berechnungsmodellen z. B. ' fur das Verhalten des 
5 Produkts bei mechanischen Belastungen, zur Fertigungsplanung, 
zur Ressourcenplanung (enterprise resource management) , zur 
Programmierung von Bearbeitungsmaschinen, zur Durchfiihrung 
und Auswertung von Messungen zur Qualitatssicherung und zum 
Abarbeiten eines Arbeit sablaufs (workflow management) . 

10 Jede dieser Anwendungen 200 verwendet eine spezifische Sicht 
auf das Produkt und benotigt bestimmte Datenobjekte 300. 
Grunde fiir die unterschiedlichen Sichten sind die, dafi jede 
Anwendung 200 spezifische Aufgaben zu erftillen hat und daftir 
spezifische Daten, Inf ormationen und Wissen benStigt und be- 
15 stiiratite Arbeit szustSnde beim ProblemlSsen erfordert. Ein Da- 
tenobjekt 300 gehOrt zu mindestens einem bestimmten Modell 
150, das seinerseits zu einer bestimmten Sicht auf das Pro- 
dukt Oder den ProzeB geh6rt und von mindestens einer Anwen- 
dung 200 fiir eine Phase des Produktentstehungsprozesses er- 
20 zeugt und bearbeitet wird. MSglich ist, daii dasselbe Modell 
von verschiedenen Anwendungen 200 bearbeitet wird. 

Diese Anwendungen sowie die zentrale Datenbank 100 sind tiber 
Infoinnaationsweiterleitungs-Schnittstellen 250 mit dem zentra- 

\ len Diensteprograram verbunden, Vorzugsweise sind keine 

25 Schnittstellen vorgesehen, die zwei Anwendungen 200. a, 200. b 
direkt miteinander oder eine Anwendung 200 mit der zentralen 
Datenbank 100 des Systems 10 verbinden. Dadurch wird der Ent- 
wicklungs- und Pflegeaufwand reduziert: Bei n Anwendungen 
200.1, ... , 200. n sind nur n Schnittstellen zwischen den An- 

30 wendungen und dem zentralen Diensteprogramm 98 erf orderlich. 
Falls direkte Schnittstellen zwischen den n Anwendungen 
200-1, ... , 200. n erforderlich waren, sind im Extremfall 
insgesamt n*(n-l)/2 Schnittstellen zu entwickeln und zu pfle- 
gen. Fiir n=10 sind dank der Erfindung nur 10 anstelle im Ex- 

35 tremfall 45 Schnittstellen zu entwickeln. Durch die zentrale 
Datenhaltung ist daruber hinaus eine Konversion zwischen an- 
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wendungsspezif ischen Produkt- oder Prozefimodellen 150 und den 
jeweils verwendeten Informations- und/oder Datenmodellen 
nicht erf orderlich . 

Fig- 2 zeigt eine beispielhaf te Architektur mit dem erfin- 
5 dungsgemaUen System 10 und vier Anwendungen 200,1^ 200*2, 

200.3 und 200.4. Die vier Anwendungen sind uber vier Informa- 
tionsweiterleitungs-Schnittstellen 250.1, 250 . 2 , 250 . 3 und 

250.4 mit dem zentralen Diensteprogramm 98 verbunden. Direkte 
Schnittstellen zwischen zwei Anwendungen 200.1 , 200. b oder 

10 eine Schnittstelle zwischen einer lokalen Datenhaltung 100.x 
und der zentralen Datenbank 100 sind nicht erf orderlich . Wei- 
terhin umfalit das System 10 eine Benut zeroberf lache 50. 

Die zentrale Datenhaltung wird vorzugsweise ausschlieJJlich 
vom zentralen Diensteprogramm 98 beschrieben und ausgelesen. 
15 Nur das zentrale Diensteprogramm 98, nicht aber die Anwendun- 
gen 200.1, 200.2, 200.3 und 200.4, haben Schreib- und Lese- 
zugriff auf die zentrale Datenbank . 100 . In der zentralen Da- 
tenbank 100 werden folgende Inf ormationen dauerhaft verwaltet 
und tiber das zentrale Diensteprogramm 98 .und den Informati- 
20 onsweiterleitungs-Schnittstellen 250 den Anwendungen verftig- 
bar gemacht: 

die Relations-Typ-Kategorien und die Taxonomie unter die- 
sen, 

die Datenobjekt-Typen 500 und die Taxonomie unter diesen 

25 - die Relations-Typen einschlielilich der Taxonomie unter 
diesen und den automatisch auswertbaren Vorschriften 

- und die Relationen 400 und die Verweise von diesen auf die 
jeweiligen Relations-Typen. 

Eine Anwendung 200.1 „kennt'' also nach einem Lesezugriff Re- 
30 lationen, z. B. eine Relation 400.1 zwischen einem Datenob- 
jekt 300.1 eines von der Anwendung 200.1 erzeugen Modells 
150.1 und einem weiteren Datenobjekt 300.3 eines Modells 
150.3, das von einer anderen Anwendung 200.3 erzeugt wurde. 
In den Modellen 150 oder lokalen Datenspeichern 110 werden 
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hingegen vorzugsweise keine Inf ormationen iiber die anderen 
Modelle abgespeichert , damit nicht ein Modell einer Anwendung 
direkte Verweise auf ein Modell einer anderen Anwendung be- 
sitzt . 

5 Datetnobjekte 300 und Anwendungen 200 zum Erzeugen, Bearbeiten 
und Auswerten von Datenobj ekten, insbesondere von Konstrukti^ 
ons- und Fertigungs-Gestaltungselemente, sind oft auf die 
spezifischen Anf orderungen der Phase zugeschnitten . Sie rep- 
rasentieren die fiir die jeweilige Phase relevanten Bestand- 
10 telle des P-rodukts oder Prozesses. Die Datenobjekte 300 und 
Relationen 400 bilden die Bausteine (building blocks) , urn Mo- 
delle 150 fiir die jeweilige Phase zu erzeugen. Ein Datenob- 
jekt 300 wird vorzugsweise nicht voiti zentralen 
Diensteprograiran 98 erzeugt^ geandert^ geloscht und verwaltet, 
15 sondern von der jeweiligen Anwendung 200. Die Anwendung 150 
stellt insbesondere die dauerhafte Speicherung des Datenob- 
jekts 300 z. B. in einer lokalen Datenbank 110 sicher. Das 
Datenobjekt 300 ist Bestandteil eines Produkt- oder ProzeBmo- 
dells 150 und steht in der Regel nur der erzeugenden Anwen- 
20 dung 200 zur VerfUgung, aber keiner anderen Anwendung. 

Das zentrale Diensteprogramm 98 vermag ein Datenobjekt 300 ti- 
ber ein Zugrif f sverf ahren anzusprechen, z. B. mit Hilfe eines 
Zugrif f spfades auf das Produkt- oder ProzeBmodell 150 und ei- 
I ne innerhalb dieses Modells eindeutige Kennung (identifier) 
25 Oder uber eine Programmierschnittstelle (application program- 
ming interface, API) zu einer Anwendung 200. Eine in der 
zentralen Datenbank 100 gespeicherte Relation 400.1 besitzt 
Verweise auf die Datenobjekte 300.1 und 300.3, die durch die 
Relation 400.1 verbunden werden. Diese Verweise umfassen alle 
30 Inf ormationen., die das zentrale Diensteprogramm 98 ftir einen 
lesenden Zugrif f auf die Datenobjekte 300.1 und 300.3 benO- 
tigt. 

Eine Anwendung 200 kann tiber eine Inf ormationsweitergabe- 
Schnittstelle 250 und das zentrale Diensteprogramm 98 die Er- 
35 zeugung und dauerhafte (persistente) Abspeicherung eines Da- 
tenobjekt-Typs 500 in d^r zentralen Datenbank 100 auslSsen. 
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Umgekehrt kann die Anwendung 200 sich Inf ormationen uber Da- 
tenobjekt-Typen 500 aus der zentralen Datenbank 100 beschaf- 
fen, z. B. urn ein Datenobjekt 300 eines bestimmten Datenob- 
jekt-Typs 500 durch Instantiierung zu erzeugen. Beispielswei- 
se wird liber eine Inf ormationsweiterleitungs-Schnittstelle 
250 an ein CAD-Werkzeug als eine Anwendung 200 geschickt, 
durch Instantiierung ein Datenobjekt 300 eines vorgegebenen 
Datenobjekt-Typs 500 zu erzeugen. Das erf indungsgemaBe System 
10 gibt einer Anwendung 200 den Typ 500 sowie den Namen und 
bestimmte Attribute und/oder Methoden des zu erzeugenden Da- 
tenobjekts 300 vor. 

Bevor eine Anwendung 200.1 eine von ihr erzeugtes und verwal- 
tetes Datenobjekt 300.1 loscht, ermittelt das zentrale 
Diensteprogramm 98, welche anderen Datenobjekte 300.3 dersel- 
ben Oder anderer Anwendungen von dieser Loschung beeinfluBt 
werden. Hierftir wird folgende Abfolge automat isch ausgeftihrt, 
vgl . Fig . 1 : 

- Die Anwendung 200.1 ubermittelt an das zentrale 
Diensteprogramm 98 eine Kennung sowie den Typ 500.1 des zu 
loschenden Datenobjekts 300.1. 

- Das zentrale Diensteprogramm 98 ermittelt mittels Lese- 
zugriff auf die zentrale Datenbank 100, durch welche Rela- 
tions-Typen der Datenobj ekt-Typ 500.1 mit anderen Datenob- 
jekt-Typen verbunden ist. Seien 600.1, ... , 600. n diese 
Typen . 

- Das zentrale Diensteprogramm 98 ermittelt die m Relationen 
400.1, .-- , 400. m, die von einem der Typen 600.1, ... , 
600. n Oder einem Untertyp dieser n Typen sind und die je 
einen Verweis auf das Datenobjekt 300.1 tragen. 

Das zentrale Diensteprogramm 98 ermittelt, welche anderen 
Datenobjekte 300.3, 300.5 mindestens einer dieser m Rela- 
tionen zugeordnet sind. Diese Datenobjekte werden von der 
geplanten Loschung beeinflulit. 

- Das zentrale Diensteprogramm 98 ermittelt, welche automa- 
tisch auswertbaren Vorschrif ten. den n Relations-Typen 
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600.1^ ... / 600. n zugeordnet sind. Durch Auswertung die- 
ser Vorschriften ermittelt das zentrale Diensteprogramm 98 
weitere Konsequenzen der geplanten Loschung, z. B. Veran- 
derung von Parametern oder Loschung weiterer Datenobjekte . 

- Das zentrale Diensteprogramm 98 ermittelt, welche Anwen- 
dungen 200.1, 200.3 mindestens eines dieser beeinf luBten 
weiteren Datenobjekte 300.3, 300.5 verwalten, und ubermit- 
telt je eine Beschreibung der Auswirkungen an die jeweili- 
ge Anwendung 200.1, 200.3. 

- Z. B. durch Abarbeitung eines Arbeitsablauf s (workflow) 
werden die erf orderlichen Freigaben fur die Loschung von 
300.1 eingeholt.. 

- Nach der LOschung streicht das zentrale Diensteprograitiin 98 
alle Verweise auf das geloschte Datenobjekt 300.1 aus den 
Relationen 400.1, ... , 400. m. Bei Bedarf werden Relatio- 
nen geloscht. 

Eine alternative Ausftihrungsf orm sieht vor, dali die Anwendung 
200.1 das Datenobjekt 300.1 lOscht und die Information iiber 
die Loschung erst nachtrSglich an das zentrale 
Diensteprogramm 98 libermittelt. 

Eine entsprechende Abfolge wird z. B. ausgefiihrt, um Informa- 
tionen dartiber zu erzeugen, mit welchen weiteren Datenobjek- 
ten ein zuvor ausgewShltes typisiertes erstes Datenobjekt 300 
in Verbindung steht. Diese Inf ormationen werden entweder 
durch direkte Auswertung von Inf ormationen oder beispielswei- 
se durch die folgende Abfolge erzeugt: 

- Ein typisiertes Datenobjekt wird ausgewahlt. 

Der Datenobj ekt-Typ dieses Datenobjekts wird ermittelt. 

- Alle Relations-Typen, denen dieser Datenobj ekt-Typ zuge- 
ordnet ist, werden ermittelt. 

- Alle weiteren Datenobj ekt-Typen werden ermittelt, die ei- 
nem dieser Relations-Typen zugeordnet sind. 

- Alle Datenobjekte dieser Typen werden ermittelt. 
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Das erf indungsgemalie System 10 iimfaBt Komponenten zur Durch- 
fuhrung dieser Erinittlungen. 

Das zentrale Diensteprogramm 98 regelt den Kontroll- und In- 
formationsfluB zwischen den Anwendungen 200 sowie zwischen 
5 einer Anwendung 200 und der zentralen Datenbank 100. Es be- 
antwortet Anfragen, die von einer Anwendung 200 uber eine In- 
f ormationsweiterleitungs-Schnittstelle 250 eingehen, lost Er- 
eignisse wie die Erzeugung eines Datenobjekts 300 aus und 
verwaltet die zentrale Datenbank 100 einschlieJJlich der Tran- 
10 saktions-Verwaltung fiir die dauerhafte Speicherung von Daten- 
objekten 300 und Relations-Typen 600, Relationen 400 und Re- 
lations-Typ-Kategorien - 

Das zentrale Diensteprograinin 98 greift z. B- rait Hilfe von 
Standard-Protokollen wie „Open Database Connectivity^'' (ODBC) 
15 auf eine relationale Datenbank, die als zentrale Datenbank 
100 fungiert, zu. Zum Abfragen dieser relationalen Datenbank 
wird z. B- die ,,Standard Query Language'' (SQL) als Standard- 
sprache fiir Abfragen von relationalen Datenbanken verwendet. 
Eine alternative Aus fuhrungs form sieht vor, zwischen zentra- 
20 lem Diensteprogramm 98 und zentraler Datenbank 100 funktiona- 
le Oder objekt-orientierte Schnittstellen in Verbindung mit 
..def inierten Programmier-Schnittstellen fUr Anwendungen (ap- 
plication programming interfaces, APIs) bereitzustellen. Das 
i zentrale Diensteprogramm 98 nutzt Funktionalitaten von Pro- 
25 grammier-Schnittstellen, um Lese- und/oder Schreibzugrif f auf 
die zentrale Datenbank 100 zu erhalten. Ein Vorteil der XML- 
Dateien ist ihre einfache Handhabbarkeit . ODBC und SQL sind 
weit verbreitete Standards. Viele Software- 

Entwicklungsumgebungen besitzen ODBC- und SQL-Schnittstellen. 
30 Ein Vorteil von Programmier-Schnittstellen ist der, daJi die 
Art der Datenspeicherung nach auBen nicht sichtbar ist und 
daher die zentrale Datenbank 100 intern geandert werden kann, 
ohne dafi deshalb das zentrale Diensteprogramm 98 oder gar An- 
wendungen 200 geandert zu werden brauchen. Anwendungen und 
35 das zentrale Diensteprogramm 98 werden vorzugsweise durch In- 
ter-ProzeB-Kommunikation miteinander verbunden, z. B. auf Ba- 
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sis von ^^Distributed Component Object Moder' (DCOM) ^ „Hyper- 
text Transfer Protocor' (HTTP) Oder ,,Coinmon Object Request 
Broker Architecture'" (CORBA) mit einer ,,Interface Definition 
Language"" (IDL) oder ..Enterprise Java Beans"" (EJB) . 

Moglich ist, daB das zentrale Diensteprogramm 98 und weitere 
Komponenten des erf indungsgemafien Systems 10 und zumindest 
einige Anwendungen 200 alle auf derselben Datenverarbeitungs- 
anlage ablaufen. Vorzugsweise umfaBt das erf indungsgemaBe 
System 10 aber eine eigene Datenverarbeitungsanlage. die als 
Netzwerk-Zentralrechner (Server) in einer Client-Server- 
Architektur fungiert. Die Datenverarbeitungseinrichtungen fur 
die Anwendungen 200 fungieren als Netzwerk-Teilnehmerrechner 
(Clients) . 

Die Erfindung untersttitzt die Integration verschiedener An- 
wendungen 200 in zwei Richtungen entlang des Produktentste- 
hungsprozesses: fluBabwarts (forward) und fluBauf warts (back- 
ward) . Die Integration f luBaufwarts wird insbesondere dadurch 
erreicht. daB die Auswirkungen einer Anderung in einer Phase 
auf nachfolgende Phasen ermittelt werden. z. B. von der Phase 
Konstruktion auf die Phase Fertigung oder auf die Phase Werk- 
zeugbau, in der abhangig von Produktmodellen 150 die zur Fer- 
tigung des Produkts benotigten Werkzeuge entworfen werden. 
Die Integration fluBabwarts hat' zur Folge, daB Anwendungen 
200 in spateren Phasen iiber Modelle 150 in frtiheren Phasen 
informiert werden. Einzelnen Datenobjekten 300 dieser frtihe- 
ren Phasen, z. B. der Phase Produkt-Konstruktion, konnen 
z. B, Konstruktions-Begrundungen (design rationale) zugeord- 
net sein^ die zu besseren Entscheidungen in spateren Phasen 
f tihren . 

Die Erfindung unterstutzt diirch die Integration beispielswei- 
se Kostenvorhersage (cost estimation) , Produktentwurf mit ei- 
nem vorgegebenen Opt imierungskr iter ium und/oder vorgegebenen 
Randbedingungen (design-to-X) , Automatisierung des Arbeitsab- 
laufs (workflow management) sowie die Handhabung von Erfah- 
rungen, Rechtf ertigungen und Begrtindungen. 
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Fiir die Kostenvorhersage ist insbesondere zu ermitteln, wel- 
che Kosten die Fertigung der Konstruktions- 

Gestaltungselemente des Produkts verursachen wird. Bei zu ho- 
hen Kosten sind einz'elne Konstruktions-Gestaltungselemente so 
zu verandern, daB die gesamten Fertigungskosten sinken. Zu 
diesen Konstruktions-Gestaltungselementen zahlen beispiels- 
weise bestimmte Bohrlocher in Zylinderkopf en. Ein Datenob- 
jekt"Typ „Bohrlocher iia Zylinderkopf' fiir die Phase Produkt- 
Konstruktion sowie mindestens ein Datenobjekt"-Typ fur Ferti- 
gungs-Gestaltungselemente zur Fertigung der Bohrlftcher werden 
eingefuhrt und durch einen Relations-Typ ,,wird gefertigt 
durch'^ miteinander verbunden. Die Fertigungs- 

Gestaltungselemente gehoren zu eineia Produktmodell 150 fur 
die Arbeit s- und Fertigungsplanung (machining planning) . Sie 
werden mit einer Anwendung 200 far die Kostenvorhersage ver- 
bunden, die z. B. eine Datenbank 110 mit Datensatzen fUr 
Werkzeuge, Bearbeitungszeiten und Stundensatzen imfafit. Dank 
der Erfindung hat die Anwendung 200^ die das Produktmodell 
150 mit den Konstruktions-Gestaltungselementen bearbeitet, 
Lesezugriff auf die Kosteninf ormationen und kann veranlassen, 
dali die Kosten fiir die Fertigung des Bohrlochs vorhergesagt 
werden . 

Die Versorgung und die Integration werden erf indungsgemSJi 
durch zwei Merkmale realisiert. Datenobjekt-Typen ftir ver- 
schiedene Phasen werden semantisch dadurch verknupft, dalS sie 
in einer einzigen Taxonomie zusammengef alit werden. Dadurch 
wird eine gemeinsame Notation z. B. von Typen und Attributen 
fur alle Phasen sichergestellt, Redundanz und doppelte Daten- 
haltung werden vermieden. Nicht erforderlich ist es^ . Trans- 
formationen zwischen Modellen fur verschiedene Phasen zu er- 
zeugen und auszuwerten. Wie oben beschreiben, spart der Ver- 
zicht auf Transformationen insbesondere viele Schnittstellen 
ein. 

Fig. 3 zeigt einen Ausschnitt aus der anwendungs- und phasen- 
tibergreifenden Taxonomie fur Datenobjekt-Typen. Ein Rechteck 
reprasentiert einen Datenobjekt-Typ. Eine Kante verbindet ei- 
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nen Untertyp mit dem oberhalb des Untertyps gezeigten Ober- 
typ. Die Rechtecke r^prSsentieren folgende Datenobjekt-Typen: 



Bezugs- 
zeichen 


Name des Datenobjekt-Typs 


500.1 


Abstrakter Typ „Datenobjekt-Typen" (engineering ob- 
ject types) 


500.2 


Gestaltungselemente der Benutzeronerixacne (user in- 
terface features) 


500.3 


Gestaltungselemente eines produktiv eingesetzten 
CAD-Werkzeugs xyz (xyz features) 


500.29 


Gestaltungselemente ( features ) 


500 . 4 


Bauteile des Produkts (parts) 


500.5 


Qualitats-Gestaltungselemente (quality learures ) 


500. 6 


Konstruktions-Gestaltungselemente 
(design features, finish part features) 


500.7 


Fertigungs-Gestaltungselemente (manufacturing fea- 
tures) 


500.8 


Rohteil-Gestaltungselemente (raw part features) 


500. 9 


Prtif -Gestaltungselemente (inspection features) 


500.10 


ftir eine Gieliform benOtigtes Bauteil (mold parts) 


500.28 


Mefi -Gestaltungselemente (measure elements) 


500.11 


Bleche (sheet metals) 


500.12 


geometrischer GrundkOrper (voliametric features) 


500 . 30 


Zer spanungs-Gestaltungselemente (machining features ) 


500.13 


Rohteil-Zylinder (raw part cylinders) 


500.14 


Auswerf er (ejectors) 


500.15 


Abziehende GrundkOrper ( subtract ive features) 


500.16 


Bohrlocher (holes) 


500.17 


Bearbeitungs-Zylinder (machining cylinders) 
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500 - lo 


Gewxnae (tnreacis; 


500 . ly 


n / -I.- «^ ^ £^ \ 

Kegex ^x:apej-s; 


500 . 20 


Fasen vcnamrers; 


500 . 21 


*l ^ «9 / \ \ 

Scniitze isxous) 


500 . 31 


eieitienuare Donjrxocnej- vsxinpxe noxes; 


500.22 


Zusammengesetztes Bohrlocher (complex holes) 


500.23 


Sacklocher (blind holes) 


500.24 


DurchgangslOcher (through holes) 


500.25 


Sacklocher mit Aufbohrung (debored blind holes) 


500.26 


Durchgangslocher mit Aufbohrung 
(debored through holes) 


500.27 


Zundkerzen-Bohrlocher (spark plug holes) 



In diese Taxonomie lassen sich insbesondere alle Typen von 
Gestaltungselementen einordnen, die aus DIN 328 69-3 bekannt 
sind- 



Datenobjekte, insbesondere Konstruktions-Gestaltungselemente 
5 (design features) und Fertigungs-Gestaltungselemente (manu- 
facturing features), werden vorzugsweise gemSfi dem objektori- 
entierten Paradigma behandelt, das aus J. Rumbaugh, M. Blaha, 
W. Premerlani, F. Eddy> W. Lorenson: ^Object-Oriented Model- 
ling and Design^^;. Prentice-Hall, Englewood Cliffs, 1991, be- 
10 kannt ist. Datenobjekte 300 werden typisiert, und Typen 500 
(types / classes) von Datenobjekten konnen Attribute oder Pa- 
rameter, die die statischen Eigenschaf ten der Datenobjekte 
beschreiben, und Methoden fur die dynamischen Eigenschaften 
der Datenobjekte besitzen. 

15 Ein Datenobjekt 300 eines vorgegebenen Datenobjekt-Typs 500 
laiit sich durch „Instantiierung'^ des Datenobjekt-Typs erzeu- 
gen. Das so erzeugte Datenobjekt besitzt die Attribute und 
Methoden des Datenobjekt-Typs. Om Redundanz unter Typen von 
Datenobjekten zu verringern, werden bevorzugt mehrere Abs- 

20 traktionsschritte durchgef uhrt . Dabei werden Gemeinsamkeiten 
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zwischen n Datenobjekt-Typen 500.1^ ... , 500. n identif iziert 
und in einem neuen, abstrakteren Datenobjekt-Typ zusammenge- 
fafit. Dieser neue Datenobjekt-Typ 500. o wird Obertyp (parent) 
von 500.1^ ... f 500. n. 500. o ist mit 500.1^ ... , 500. n 
durch eine Spezialisierungs-Relation verbunden. Das Ergebnis 
der Abstraktionsschritte ist eine Taxonomie unter Datenob- 
jekt-Typen 500. Blatter dieser Taxonomie, also Datenobjekt- 
Typen ohne Untertypen, konnen instantiiert werden, die abs- 
trakteren Datenobjekt-Typen vorzugsweise nicht. 

Fur die erf indungsgemalien Relationen 400 zwischen Datenobjek- 
ten 300 werden entsprechende Typisierungen durchgef uhrt . Da- 
durch entstehen Relations-Typen 600,. aus denen durch Instan- 
tiierung Relationen 400 erzeugt werden konnen. Durch entspre- 
chende Abstraktionen der Relations-Typen 600 werden Relati- 
ons-Typ-Kategorien und eine Taxonomie unter diesen Relations- 
Typ-Kategorien erzeugt. 

Eine Relation 400 verbindet mindestens zwei Datenobjekte 
300. a und 300. b. Eine Relation 400 fungiert als Baustein 
(building block) fiir die Verwaltung und Auswertung der Abhan- 
gigkeiten zwischen Datenobjekten 300. a, 300. b, Eine Relation 
4 00. a kann auch eine andere' Relation 400. b mit einem oder 
mehreren Datenobjekten 3 00. a, 300.b verbinden oder aber meh- 
rere andere Relationen miteinander verbinden. Entsprechend 
verbindet ein Relations-Typ 600 mindestens zwei Datenobjekt- 
Typen 500. a und 500. b miteinander. Ein Relations-Typ 600. a 
kann auch einen anderen Relations-Typ 600 .b mit einem oder 
mehreren Datenobjekt-Typen 500 verbinden oder aber mehrere 
andere Relations-Typen miteinander verbinden. 

Ein Beispiel fiir eine Relation, die andere Relationen mitein- 
ander verbindet, sind Datenobjekte und Relationen fur ein 
Lochbild, das sind mehrere Locher mit bestimmten Positionen 
relativ zueinander, die aus einem Blech ausgestanzt werden. 
Ein Datenobjekt-Typ „Bohrlocher^^ mit den beiden Untertypen 
,,Referenz-Bohrl5cher^^ und ,,abhangige BohrlScher^^ werden ein- 
geftihrt. Die n Locher eines Lochbildes werden durch ein Da- 
tenobjekt des Typs ,,Ref erenz-BohrlOcher^^ und n-1 Datenobjekte 
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des Typs ,,abhangige Bohrlocher"" reprasentiert . Die absolute 
Soil-Position des Ref erenz-Bohrlochs und die relativen Posi- 
tionen 'der n~l abhangigen Bohrlocher werden vorgegeben und 
durch entsprechende Attribute reprasentiert - Weiterhin werden 
5 ein Datenobjekt des Typs „Lagetoleranz^' und n-1 Datenobjekte 
des Typs ^,MeIi-Toleranzen^^ erzeugt und dem Ref erenz-Bohrloch 
bzw. den n-1 abhangigen Bohrlochern mittels Relationen zuge- 
ordnet . 

Ein Relations-Typ ,,Relativposition^^ und n-1 Relationen dieses 
10 Typs werden erzeugt. jede Relation dieses Typs verbindet das 
Referenz-Bohrloch, ein abhangiges Bohrloch und eine MeI5- 

• Toleranz miteinander • Der Relations-Typ ,,Relativposition'' ist 
mit den Datenobj ekt-Typen ,,Ref erenz-Bohrlocher^\ ,,abhangige 
Bohrlocher^^ und „MeJi-Toleranzen^^ verbunden. Er umfafit eine li- 
15 berpriifende Vorschrift fur die Relativ-Position des abhangi- 
gen Bohrlochs relativ zum Ref erenz-Bohrloch des Lochbildes. 
Die Vorschrift nimmt Bezug auf die durch das dritte Datenob- 
jekt vorgegebene MeBtoleranz. Jede Relation des Typs ^/Rela- 
tiv-Position^' „kennf diese Vorschrift. Bei Auswertung der 
20 Relation ermittelt das erf indungsgemalie System 10 die benfi- 
tigten Attribute der drei Datenobjekte und setzt sie in die 
Vorschrift ein, Oberprtift wird durch die Auswertung der Vor- 
schrift^ ob die Relativ-Position die vorgegebene MeBtoleranz 

• einhalt. Ein weiterer Relations-Typ namens „Lochbilder'' wird 
25 eingefiihrt. Pro Lochbild wird eine Relation dieses Typs er- 
zeugt ^ welche die gerade beschriebenen n-1 Relationen des 
Typs „Relativ-Position'^ miteinander verbindet. Ober diese Re- 
lation kann das zentrale Diensteprogramm 98 auf alle Datenob- 
jekte und Relationen, die das Lochbild reprasentieren, 
30 zugreifen. 

Eine abweichende Ausf iihrungsf orm dieses Beispiels sieht vor, 
N Untertypen des Datenobj ekt-Typs „abhangige Bohrlocher^' zu 
erzeugen;. wobei N die maximal mogliche Loch-Anzahl eines 
Lochbildes ist. Die n-1 Datenobjekte fur die n-1 abhangigen 
35 Bohrlocher des Lochbildes gehoren zu n-1 verschiedenen der N 
Datenobj ekt-Typen. Dank dieser Ausf iihrungsf orm laJit sich 
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durch Kenntnis nur des jeweiligen Datenobjekt-Typs ein be- 
stimmtes abhangiges Bohrloch adressieren. 

Sonderf'aile von Datenobjekt-Typen sind die Typen ,,Kommenta- 
re^\ „Benutzer-Hilfen^\ ^,Erf ahrungsobjekte^' und ^Dokumentati- 
5 onen^^ . Ein Erf ahrungsobjekt umfaBt Texts, Bilder und/oder 
Bildfolgen, die Erfahrungen itiit einem anderen Datenobjekt o- 
■ der einer Relation oder Begriindungen z. B. fur eine Entwurfs- 
entscheidung (design rationale) beschreiben. Fur alle diese 
Typen wird der Obertyp ,,Erlauterungen'' eingefuhrt. Ein Daten- 
10 objekt des Typs „Erlauterungen^' ist durch eine Relation mit 
mindestens einem anderen Datenobjekt,. z. B. einem Gestal- 
tungselement oder einem Bauteil, einem Datenobj ekt-Typ oder 
einer Relation oder einem Relations-Typ oder einer Relations- 
Typ-Kategorie verbunden. Dieselbe Erlauterung kann verschie- 
15 denen Datenobjekten zugeordnet sein, Moglich ist, eine Erlau- 
terung zunachst einem Datenobjekt zuzuordnen und spater nach 
einem FreigabeprozeB dem entsprechenden Datenobjekt-Typ. Die 
Relationen zwischen Erlauterungen einerseits und anderen Da- 
tenobjekten, Relationen, Typen oder Relations-Typ-Kategorien 
20 andererseits werden ebenfalls typisiert, z. gehOren sie . 

alle einem Relations-Typ • ,,.Erlauterungs-Zuordnung^^ an. 

In Abhangigkeit von den automatisch auswertbaren Vorschriften 
werden zwei Arten von Relationen unterschieden, namlich uber- 
i prtifende und generische Relationen. Entsprechend werden liber- 
25 prufende und generische Relations-Typen unterschieden. 

Ein uberpruf ender Relations-Typ beschreibt durch die zugeord- 
neten uberpruf enden Vorschriften mindestens eine logische Ab- 
hangigkeit zwischen Datenobjekten. Gepriift wird, ob die exis- 
tierenden Datenobjekte mit den Vorschriften vereinbar sind. 
30 Neue Datenobjekte werden nicht erzeugt. Eine Sonderform einer 
tiberpruf enden Vorschrift ist ein Attribut des Relations-Typs . 
Dieses Attribut kennzeichnet beispielsweise eine Relation und 
damit eine Abhangigkeit zwischen Datenobjekten verschiedener 
Anwendungen 200.1, 200.2 naher. 
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Ein Beispiel: Ein Zylinderkopf umfaJit n Ktihlrippen. Diese 
werden in der Phase Konstruktion durch n Konstruktions- 
Gestaltungselemente modelliert. Ein Grundkorper fur den Zy- 
linderkopf wird um diese n Konstruktions-Gestaltungselemente 
5 erganzt, Bei der Fertigung des Zylinderkopf s werden die Ktihl- 
rippen erzeugt, indem Aussparungen aus einem Block gefrast 
werden. Diese auszuf rasenden Aussparungen werden in der Phase 
Arbeit splanung durch Fertigungs-Gestaltungselemente model- 
liert. Um die Abhangigkeiten zwischen diesen Gestaltungsele- 
10 menten zu erfassen, wird ein Typ von Relationen zwischen n 
Konstruktions-Gestaltungselementen fiir die Phase Konstruktion 

•und m Fertigungs-Gestaltungselementen fur die Phase Arbeits- 
planung eingefuhrt. Eine solche Relation verbindet n Kahlrip- 
pen und m Ausfrasungen an einem Zylinderkopf . 

15 Um festzulegen, wle viele Datenobjekte diese Relation verbin- 
det^ werden zwei Mitgliedschaf ts-Intervalle (Kardinalitaten) 
far den Relations-Typ festgelegt. Das erste Mitgliedschaf ts- 
Intervall schrankt die Anzahl der KUhlrippen ein,r das zweite 
die Anzahl der Ausfrasungen. Ein Mitgliedschaf ts-Intervall 

20 hat z. B. die Form a:b, wobei a eine nattirliche Zahl und b 
eine nattirliche Zahl oder * ist. Die Festlegung * steht fur 
eine beliebig groBe Anzahl von Datenobjekten. 

Vorzugsweise werden dem Relations-Typ weiterhin zwei fremde 

•I Rollen zugeordnet^ namlich die Rollen ,,als Konstruktions- 
25 Gestaltungselemente^^ und ^/als Fertigungs- 

Gestaltungselemente^^ . Dadurch wird festgelegt, welche Rollen 
die verbundenen Datenobjekte in einer Relation des Typs ,,aus 
Sicht der Rolle^^ spielen. Im allgemeinen Fall sind vorzugs- 
weise n Mitgliedschaf ts-Intervalle und n Rollen fur einen Re- 
30 lations-Typ festgelegt, die n Datenobjekt-Typen und/oder Re- 
lations-Typen miteinander verbindet- Diese Ausgestaltung er- 
moglicht es, effizient m: n-Beziehungen zu modellieren. 

Weiterhin wird einem Relations-Typ eine Kennzeichnung der ei- 
genen Rolle zugeordnet, das ist die Rolle, die eine Relation 
35 des Typs aus Sicht der verbundenen Datenobjekte spielt. Der 
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Unterschied zwischen fremden Rollen und eigener Rolle wird an 
folgendem Beispiel erlautert: 

Zwei Datenobj ekt-Typen ^,Konstruktions-Gestaltungselemente'^ 
(design features) und '.^Fertigungs-Gestaltungselemente^^ (manu- 
5 facturing features) werden erzeugt. Der Datenobj ekt-Typ „Kon- 
struktions-Gestaltungseleitiente^' hat u. a. den Untertyp „Zwei- 
Stuf en-Bohrlocher^^ r der Datenobj ekt-Typ „Fert igungs- 
Gestaltungselemente'^ den Untertyp „Bohrungen^' . ,,Zwei-Stuf en- 
Bohrlocher'^ und ,,Bohrungen^^ werden einem Relations-Typ ,,wird 

10 gefertigt als^' so zugeordnet, daJi eine Relation des Typs ein 
Zwei-Stuf en-Bohrloch mit zwei Bohrungen verbindet. Dem Rela- 
tions-Typ werden die eigenen Rollen „Fertigungs-Sicht^^ (aus 
Sicht der Konstruktions-Gestaltungselemente) und ,,Fertigteil- 
Sicht^' (aus Sicht der Fertigungs-Gestaltungselemente) zuge- 

15 ordnet. Weiterhin werden dem Relations-Typ die fremden Rollen 
,,obere Bohrung^^ und ,,untere Bohrung^^ (aus Sicht des Zwei- 
Stuf en-Bohrlochs) sowie „Stuf en-Bohrloch'^ (aus Sicht der Boh- 
rungen ) zugeordnet - 

Die dem Relations-Typ namens ,,wird gefertigt durch^' zugeord- 
20 nete Vorschrift legt z. B. fest, welche und wie viele Ferti- 
gungs-Gestaltungselemente ftlr gegebene Konstruktions- 
Gestaltungseleraente erforderlich sind. Die tiberprtif ende Vor- 
schrift besagt z. B., daB m = n - 1 gelten muB . Sie kann Be- 
zug auf die beiden Mitgliedschaf ts-Intervalle nehmen. Falls 
25 beispielsweise zehn Konstruktions-Gestaltungselemente, aber 
nur ftinf Fertigungs-Gestaltungselemente erzeugt wurden^ so 
wird durch Anwendung der Vorschrift ein Widerspruch entdeokt 
und gemeldet . 

Die fehlenden Fertigungs-Gestaltungselemente werden nicht au- 
30 tomatisch erzeugt. Es liegt in der Verantwortung der jeweili- 
gen Anwendung 200, an die der Widerspruch gemeldet wird, oder 
ihrer Benutzer, diesen zu beseitigen. 

Oberpruf ende Relationen kSnnen auch sogenanntes ontologisches 
Wissen tiber semantische Zusammenhange zwischen Datenobj ekt- 
35 Typen besitzen. Sie erlauben einen konsistenten Informati- 
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onsfluB entlang des Produktentstehungsprozesses und verkntip- 
fen Anwendungen auf der Inf ormationsebene und nicht nur auf 
der Datenebene. 

Eine generierende Relation umfaiSt mindestens eine automatisch 
auswertbare Generierungsvorschrift^ die festlegt, wie Daten- 
objekte automatisch erzeugt werden. Diese Vorschrift ist ei- 
nem Typ generierender Relationen zugeordnet und legt das ge- 
wtinschte Ergebnis eines Generierungsschritts fast. Vorzugs- 
weise iibermittelt das zentrale Diensteprogramm 98 dieses ge- 
wiinschte Ergebnis an die jeweiligen Anwendungen 200, Es liegt 
in der Verantwortung dieser Anwendungen 200 und bei . Bedarf 
ihrer Benutzer^ das gewiinschte Ergebnis zu erzeugen. 

Diese Vorschriften konnen von Bedingungen in Produktmodellen 
150 abhangen oder von diesen oder von anderen definierten Er~ 
eignissen (events) ausgelost werden. Beispielsweise wird nach 
jeder Anderung eines anwendungsspezif ischen Modells fiir eine 
Phase ermittelt, welche Datenobjekte von der Anderung 
beeinfluftt sind und welche generierenden Relationen sich auf 
diese Datenobjekte beziehen. Eine Anderung des Produkt- 
Modells lost eine automatische Auswertung der aufgrund der 
Anderung ermittelten generierenden Relationen aus . Generie- 
rende Relationen automatisieren damit Aufgaben des Produkt- 
entstehungsprozesses . 

Vorzugsweise verkniipft eine generierende Relation die Daten- 
objekte, die einen Generierungsschritt auslosen, mit denjeni- 
gen Datenobjekten, die bei diesem Generierungsschritt erzeugt 
werden, z. B. durch „Instantiierung^^ • Die Generierungsvor- 
schrift, die dem jeweiligen Typ generierender Relationen zu- 
geordnet ist, umfafit alle Inf ormationen, die erforderlich 
sind, urn Datenobjekte in einem bestimmten Produkt- oder Pro- 
zelimodell zu instantiieren . 

Eine von einer generierenden Relation umfaiJte Vorschrift ge- 
neriert z. B. eine Gruppe von miteinander durch Relationen 
verbundenen Gestaltungselemente (feature constellation) . 
Nicht nur die Datenobjekt-Typen werden instantiiert, urn die 
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verbundenen Gestaltungselemente zu erzeugen, sondern auch die 
Relations-Typeri;. um die verbindenden Relationen zu erzeugen, 
Ein Generierungsschritt wird beispielsweise immer dann ausge- 
lost^ wenn ein vorab spezif iziertes Datenobjekt verandert o- 
der instantiiert wird. Die Festlegung, wodurch ein Generie- 
rungsschritt ausgelost wird, wird erf indungsgemaJS einem Rela- 
tions-Typ zugeordnet. Eine Vorschrift, die einem Relations- 
Typ zugeordnet ist, wird beispielsweise von einer Komponente 
des erf indungsgemaBen Systems 10 interpretiert . Oder aber das 
zentrale Diensteprogramm 98 leitet die Vorschrift an eine In- 
ferenzmaschine 60 weiter, welche die automatische Auswertung 
vornimmt und ihr Ergebnis, also das gewunschte Ergebnis einer 
Generierung, an das zentrale Diensteprograinm 98 zuruckmeldet • 
Weil die Inf erenzmaschine 60 komplexe Auswertungen durch- 
fuhrt, ist es oft von Vorteil, sie als eigene Anwendung ge- 
trennt vom zentralen Diensteprogramm 98 zu realisieren. 

Die Verwendung von Relations-Typ-Kategorien/ Relations-Typen 
und Relationen wird an einem Beispiel erlSutert. Fur einen 
ProduktentstehungsprozeB eines Automobil-Herstellers^ der ftir 
jede seiner neuen Baureihen giiltig ist, wird in der anwen- 
dungsUbergreif enden Standard-Bibliothek ein Datenob j ekt-Typ 
„L6cher^^ eingefuhrt und der Phase Produkt-Konstruktion zuge- 
ordnet. Die Datenobjekte dieses Typs sind Konstruktions- 
Gestaltungselemente (design features) . Weiterhin wird ein Typ 
von Qualitats-Gestaltungselementen (quality features) namens 
„Funktions-Toleranzen^^ mit den Untertypen „Formtoleranzen'\ 
„Lagetoleranzen^' und „MeI5toleranzen^^ eingefuhrt und der Phase 
„Konstruktion'' zugeordnet. Der Typ „Locher''' erhalt einen Un- 
tertyp ,,Bohrlocher^^ und dieser einen Untertyp ,,Bohrlocher ftir 
Karosserie^^ . Diese Ausgestaltung berucksichtigt , daB die Kon- 
strukteure bereits in der Phase „Konstruktion^' funktionale 
Toleranzen z. B. ftir Konstruktions-Gestaltungselemente fest- 
legen. In der Phase „Produktionsplanung^^ werden weitere Tole- 
ranzen festgelegt, z. B. solche zur Oberwachung des Ferti- 
gungsprozesses und insbesondere der zur Herstellung des Pro- 
dukts verwendeten Beatbeitungsmaschinen und Werkzeuge. 
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Der Phase Qualitatssicherung wird ein Typ von Mefi- 
Gestaltungselementen (measuring features) namens ^^.MeBpunkte^^ 
zugeordnet. Jedes Meli-Gestaltungseleraent reprasentiert einen 
Abtastpunkt^ dessen tatsachliche. Position und/oder Orientie- 
5 rung wahrend der Qualitatssicherung ermittelt und mit einer 
Soli-Position und/oder Soll-Orientierung verglichen wird, 

Drei. Kategorien von Datenobjekten werden erzeugt, namlich die 
Kategorie der Konstruktions-Gestaltungseleinente, die der Qua- 
litats-Gestaltungselemente und die der Meii- 

10 Gestaltungselemente, Eine Relations-Typ-Kategorie namens 
,,MeJistrategien^^ wird eingefiihrt. Festgelegt wird, 

- daB ein Relations-Typ dieser Kategorie drei Datenobjekt- 
Typen verbindet, nSmlich einen Typ von Konstruktions- 
Gestaltungselementen einen Typ von Qualitats- 

15 Gestaltungselementen und einen Typ von MeB- 

Gestaltungselementen^ 

- und welche Parameter ein Relations-Typ der Kategorie min- 
destens haben mufi, vorzugsweise mindestens einen Namen und 
eine MeBstrategie, formula ert z. B. mit Hilfe der Dokumen- 

20 ten-Beschreibungssprache ,,eXtended Markup Language^^ (XML) 

Oder als Freitext. 

Jeder Relations-Typ der Kategorie ,,MeJistrategien^^ verbindet 

•somit einen Typ von Konstruktions-Gestaltungselementen^ einen 
Typ von Qualitats-Gestaltungselementen und einen Typ von Meli- 
25 Gestaltungselementen miteinander. 

Ein tiberpriifender Relations-Typ der Kategorie ,,MeBstrategien'' 
wird erzeugt, mit dem Namen ,,wird uberprtift durch^^ versehen 
und der Kategorie ,,Mefistrategien''^ zugeordnet. Der Relations- 
Typ ,,wird uberprtlft durch^^ verbindet drei Datenobjekt-Typen 
30 miteinander, namlich die Typen ,,Bohrl6cher^' , „Loch-Toleranz^^ 
und „MeJ5punkte'^ • Diesem Relations-Typ wird z. B. folgende ii- 
berpruf ende Vorschrif t zugeordnet : 

Fiir jedes Konstruktions-Gestaltungselement k, jedes Quali- 
tats-Gestaltungselement qu und jedes MeB-Gestaltungselement m 
35 gilt: 
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Falls der Typ von k gleich „Bohrl6cher fur Karosserie^' ist, 
gilt: 

Falls der Durchmesser von k kleiner als 0,5 mm ist und die 
Toleranz von qu gr5Iier 0,1 mm ist, dann ist die Anzahl von m 
gleich 5. 

Falls der Durchmesser von k kleiner als 0,5 mm ist und die 
Toleranz von qu kleiner gleich 0,1 mm ist, dann ist die An- 
zahl von m gleich 8 . 

Falls der Durchmesser von k zwischen 0,5 mm und 5 mm ist, 
dann ist die Anzahl von m gleich 10. 

Falls der Durchmesser von k groBer als 5 mm ist, dann ist die 
Anzahl von m gleich 20. 

Die „Anzahl von m^^ bezeichnet die Anzahl von MeBpunkten, die 
dem Bohrloch zugeordnet sind und mit denen die Einhaltung der 
geforderten Toleranz tiberpriift wird. 

AuBerdem ermoglicht die Erfindung eine „bidirektionale Asso- 
ziativitat^' zwischen Datenobjekt-Typen . Dies wird am folgen- 
den Beispiel erlSutert. Zwei Datenobjekt-Typen A und B besit- 
zen die drei Parameter x und y (Parameter von A) bzw, z (Pa- 
rameter von B) . Eine automatisch auswertbare uberpriif ende 
Vorschrift legt fest, daJ3 B.z = A.x * A.y ist. Falls zwei 
dieser drei Parameter bekannt sind, lalit sich der dritte au- 
tomatisch berechnen. Falls fur zwei Parameter obere und/oder 
untere Schranken bekannt sind, lassen sich eine obere 
und/oder untere Schranke fur den dritten Parameter aufstel- 
len. Beim Erzeugen der Vorschrift braucht nicht bekannt zu 
sein, welche die bekannten und welches der unbekannte Parame- 
ter sein wird. Werkzeuge zur automatischen Gleichungs- und 
Ungleichungsl5sung (constraint solver) vermogen vielmehr eine 
mehr solche Gleichung automatisch nach der Unbekannten auf zu- 
lOsen. Solche Werkzeuge sind z. B. aus WO 00/31640 A2 und 
US 5,477,450 bekannt. 

GemaB der Erfindung wird die Vorschrift B.z = A.x * A.y einem 
Relations-Typ R zugeordnet, dem die Datenobjekt-Typen A und B 
zugeordnet sind. Falls eine Anwendung 200 ein Datenobjekt b 
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des Typs B erzeugt hat and der Wert fur b.z bestimmt werden 
soli, so wird f estgestellt , durch welche Relation b mit ande- 
ren Datenobjekten verbunden ist, und eine Relation r des Typs 
R wird hierdurch ermittelt. Durch Lesezugriff auf R wird die 
5 Vorschrift B.z = A.x * A.y ermittelt und automatisch ausge- 
wertet. Analog wird vorgegangen, wenn ein Datenobjekt a des 
Typs A erzeugt wurde und der Wert fur a.x zu bestimmen ist. 

Wurde die Vorschrift B.z = A.x * A.y hingegen dem Datenob- 
jekt-Typ B zugeordnet, so muftten dann, wenn der Wert fur a.x 
10 zu ermitteln ist, saititliche Datenobj ekt-Typen durchsucht wer- 
den, urn den Datenob jekt-Typ B und dort eine anwendbare Vor- 
schrift zu finden. U. U. muJiten hierfur sogar andere Anwen- 
dungen 200 konsultiert werden. 

Das erfindungsgemaJJe System 10 automatisiert die Kooperation 
15 zwischen verschiedenen Anwendungen 200 und damit die Automa- 
tisierung von Aufgaben des Produktentstehungsprozesses liber 
verschiedene Phasen und Anwendungen 200 hinweg. Beispielswei- 
se ubermittelt eine Anwendung 200.1 an das zentrale 
Diensteprogramm 98, dafi die Anwendung 200.1 ein Datenobjekt 
20 300.1 eines vorgegebenen Typs durch Instantiierung erzeugen 
wird. Dieses Datenobjekt 300.1 gehort zu einem Produktmodell 
150.1, das durch die Anwendung 200.1 erzeugt und bearbeitet 
wird. Das zentrale Diensteprogramm 98 stellt den Typ 500.1 
des zu erzeugenden Datenobjekts 300.1 fest und ermittelt, 
25 welche Relations-Typen diesen Datenobj ekt-Typ 500.1 mit ande- 
ren Datenobj ekt-Typen verbinden. Falls es solche Relations- 
Typen nicht gibt oder falls diesem Relations-Typen aus- 
schlieBlich uberprttfende Vorschrift en zugeordnet sind, meldet 
das System 10 an die Anwendung 200.1, daB die Erzeugung des 
30 Datenobjekts 300.1 fortgesetzt werden kann. Bei Bedarf iiber- 
mittelt es Namen und Attributwerte far das Datenobjekt 300.1 
an die Anwendung 200.1. Falls hingegen ein Relations-Typ mit 
einer generierenden Vorschrift ermittelt wird, so wertet die 
Inferenzmaschine 60 diese aus. Das Ergebnis hangt von dem zu 
35 erzeugenden Datenobjekt 300.1 des Typs 500.1 ab, beispiels- 
weise besteht es daraus, daB n Datenobj ekte eines Typs 500.2 
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und r Datenobjekte eines weiteren Typs 500.3 sowie Relationen 
zwischen dem neuen Datenobjekt des Typs 500.1/ den n neuen 
Datenobjekten des Typs 500.2 und den r neuen des Typs 500.3 
zu erzeugen sind. Die Inf erenzmaschine 60 iibermittelt dieses 
5 Ergebnis an das zentrale Diensteprogramm 98. Das zentrale 
Diensteprograinm 98 ermittelt/ welche Anwendungen 200 von die- 
sem Ergebnis beeinflulit sind^ z. B. die auslosende Anwendung 
200.1 und/oder weitere Anwendungen. Jede beeinflufite Anwen- 
dung 200. b erhalt die Mitteilung, welche Datenobjekte sie zu 
10 erzeugen hat, z. B. welche die n des Typs 500. 2, welche die r 
des Typs 500.3. Die Erzeugung dieser Datenobjekte liegt in 
der Verantwortung der jeweiligen Anwendungen. Nachdem die An- 
wendungen 200 die Datenobjekte 300 fiir ihre jeweiligen Pro- 
duktmodelle 150 vollstandig erzeugt haben, melden diese an 
15 das zentrale Diensteprograinm 98 zuruck, daii die Erzeugungs- 
Vorschiage ausgeftihrt wurden. 

Ein ahnlicher Ablauf wird ausgel6st, wenn eine Anwendung 200 
ein bereits bestehendes Datenobjekt 300 verSndert Oder loscht 
(change management) . Wird ein Relations-Typ 600 mit einer u- 
20 berprafenden Vorschrift ermittelt, so wird diese angewendet, 
um zu priifen, ob nach der Anderung immer noch ein konsisten- 
ter Zustand vorliegt oder ob beispielsweise die Anderung eine 
automatisch ausfuhrbare und einem Relations-Typen zugeordnete 
Vorschrift verletzt. 

25 Das erf indungsgemaBe System 10 unterstutzt darUber hinaus die 
simultane Zusammenarbeit verschiedener Anwendungen 200 (con- 
current engineering) . Oft haben Anderungen, die eine erste 
Anwendung 200.1 an einem ersten Modell 150.1 des Produkts o- 
der Prozesses vornimmt, Auswirkungen auf ein zweites Modell , 
30 das von einer zweiten Anwendung 200.2 bearbeitet wird. Jedoch 
hat die erste Anwendung 200.1 keinen Schreibzugrif f auf das 
zweite Modell 150.2, well die Bearbeitung des zweiten Modells 
in der Verantwortung der Benutzer der zweiten Anwendung 200.2 
liegt. In diesem Fall ermittelt das System 10, welche Daten- 
35 objekte des ersten Modells 150.1 von der Anderung betroffen 
sind. Es stellt fest, welche Relationen dieses Datenobjekt 
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mit anderen Datenobjekten verknapfen und welche Vorschriften 
den Typen dieser Relationen zugeordnet sind. Durch Auswertung 
dieser Vorschriften wird ermittelt, welche weiteren bereits 
exist ierenden Datenobjekte wie verandert werden miissen und 
5 welche neuen Datenobjekte erzeugt werden miissen^ damit auch 
nach der Anderung das zweite und das erste Modell zueinander 
konsistent sind. Die dergestalt erzeugten Inf ormationen wer- 
den als Vorschlage an die zweite Anwendung 200.2 gesandt. Es 
liegt in der Verantwortung der Benutzer der zweiten Anwen- 
10 dung, ob diese Vorschlage realisiert werden oder nicht und 
wenn ja wie. 

•Um die Datenobj ekt-Typen 500 und Relations-Typen 600 abzu- 
speichern, werden vorzugsweise eine Vorgehensweise und ein 
Datenmodell gewahlt, das unabhangig von einer bestiinmten An- 
15 wendung ist. Eine Ausfuhrungsf orm sieht vor, die Syntax ,,eX- 
tended Markup Language^' (XML) mit „XML Schema Definition'' 
(XSD) zu verwenden und Informationen als ASCII-Text oder Text 
im Format Unicode abzuspeichern- Beispielsweise werden Infor- 
mationen aber Datenobj ekt-Typen 500 und Relations-Typen 600 
20 in verschiedenen Dateien und/oder Tabellen einer relationalen 
Datenbank abgespeichert- Jeder Typ wird als eine eigene XML- 
Entitat in einem eigenen Datensatz einer Tabelle abgespei- 
chert. Anwendungen 200 haben tiber definierte Inf ormationswei- 

•terleitungs-Schnittstellen 250 Lese- und Schreibzugrif f auf 
25 die zentrale Datenbank 100 des erf indungsgemaJJen Systems 10 
als zentraler Datenhaltung. Vorzugsweise werden hierfur Stan- 
dards wie „Open Database Connectivity'' (ODBC) zur Verbindung 
mit relationalen Datenbanken und die „Standard Query Langua- 
ge" (SQL) als Standardsprache fiir Abfragen von relationalen 
30 Datenbanken verwendet. Diese Ausfuhrungsf orm ermoglicht es, 
jede SQL- und ODBC-fahige relationale oder objektorientierte 
Datenbank einzusetzen und bei Bedarf nachtraglich eine Daten- 
bank durch eine andere zu ersetzen, ohne erneut Daten einge- 
ben Oder das zentrale Diensteprogramm 98 oder gar eine Anwen- 
35 dung 200 verandern zu miissen. 
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Datenobjekte 300 warden vorzugsweise -gemeinsam mit dem jewel- 
ligen Produktitiodell 150 abgespeichert , Relationen hingegen 
getrennt von den Anwendungen 200 in der zentralen Datenbank 
100 gemeinsam mit den Typen. Die Benutzeroberf lache 50 des 
5 erf indungsgeitiaBen Systems 10 wird vorzugsweise getrennt vom 
zentralen Diensteprogramm 98 realisiert. Damit kann die Be- 
nutzeroberf lache 50 auf verschiedene Benutzer zugeschnitten 
und ^personalisiert^^ warden, ohne die Datenhaltung an ver- 
schiedene Benutzergruppen . anpassen zu mtissen. Beispielsweise 
10 werden einem erfahrenen Benutzer mehr Handlungsmoglichkeiten 
angeboten als einem Neuling, ein Neuling erhSlt hingegen mehr 
Hilf est ellungen . 

Das zentrale Diensteprogramm 98 erzeugt und verwaltet daruber 
hinaus vorzugsweise Modelle ftir die Lese- und Schreibberech- 
15 tigungen, das Verhalten, die Fahigkeiten und die Vorlieben 
von Benutzern, die mindestens eine der Anwendungen 200 benut- 
zen (user modeling) . Diese ,,Benutzer-Prof ile^^ (user profiles) 
werden in der zentralen Datenbank 100 verwaltet. Hierbei wer- 
den z. B. die Benutzer in verschiedene Klassen kategorisiert . 
20 Die Anwendungen 200 haben Lesezugriff auf diese Profile und 
erzeugen lokale Benutzeroberf lachen der Anwendungen, die auf 
den jeweiligen Benutzer zugeschnitten sind. Weil diese Profi- 
le und Berechtigungen ftir die Benutzer zentral gespeichert 

•und verwaltet werden, brauchen sie nur einmal erzeugt und ge- 
25 pflegt zu werden. Nicht erforderlich ist es, daiS jede Anwen- 
dung 200 solche Profile separat verwaltet. Dies ist zwangs- 
laufig mit doppelter Datenhaltung und erheblich hoherem Auf- 
wand verbunden. 

Zu einem Benutzerprof il gehoren vorzugsweise auch Informatio- 
30 nen, die festlegen, wie die Datenobjekt -Typen dem jeweiligen 
Benutzer prasentiert werden. Neben Festlegungen zur Darstel- 
lungsform wird festgelegt, in welcher Reihenfolge welche Da- 
tenobjekt-Typen in einem Navigations-Baum auftreten, der dem 
Benutzer prasentiert wird. Dieser Navigations-Baum kann mit 
35 der Taxonomie iibereinstimmen, aber auch anders aufgebaut sein 
und nicht alle abstrakten Datenobjekt-Typen (Typen mit Unter- 
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typen) zeigen, z. B. nur die instantiierbaren Datenobjekt- 
Typen. Der Navigations-Bamn fur einen bestimmten Benutzer 
wird so aufgebaut, daJi der Benutzer bestimmte Datenobjekt- 
Typen mit wenigen Operationen (z, B. ^,Ausklappen^^ und Auswah- 
5 len) erreicht. Datenobjekt-Typen, die ein Benutzer haufig 
verwendet,. erreicht er schneller als andere Datenobjekt- 
Typen - 

Das erf indungsgemalie System 10 besitzt eine Benutzeroberf la- 
che 50^ die vorzugsweise den Benutzern der Anwendungen 200 
10 verborgen ist und von einem Verwalter und Administrator der 
zentralen Datenbank 100 und des zentralen Diensteprogramms 98 
benutzt wird. 

Im folgenden werden die beiden Syntaxen ftir zwei beispielhaf- 
te Datenmodelle skizziert. Das erste Datenmodell^ im folgen- 
15 den Klassenmodell genannt, legt fest, wie Ressourcen- 
Kategorien^r Ressourcen-Typen und Datenobj ekt-Typen in der 
zentralen Datenbank 100 abgespeichert werden. Das zweite Da- 
tenmodell, im folgenden Instanzenmodell genannt, legt fest, 
wie Ressourcen (--Instanzen) in der zentralen Datenbank 100 ab- 
20 gespeichert werden. Die Syntax des Instanzenmodells laBt sich 
auch zur Abspeicherung von Datenobj ekten verwenden. Die Fest- 
legungen fur beide Datenmodelle lassen sich z. B. mit Hilfe 
von XML und XSD realisieren.- 

Die Syntax ftir das Klassenmodell legt folgendes fest: 

25 • Auf oberster Ebene umfalit das Klassenmodell mindestens ei- 
ne Klasse, auiierdem bei Bedarf eine Festlegung^ welche 
Version des Klassenmodells verwendet wird. Das Klassenmo- 
dell kann beliebig viele Klassen umfassen. 

• Fur eine Klasse werden folgende Inf ormationen festgelegt: 

30 - ob die Klasse eine Ressourcen-Kategorie, ein Ressourcen- 

Typ Oder ein Datenobj ekt-Typ ist, 

- eine interne Kennung sowie mindestens einen nach auBen 
sichtbaren Namen der Klasse - vorzugsweise wird ein Name 
pro verwendete nattirliche Sprache abgespeichert. 
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- welche einfachen Parameter die Klasse besitzt, wobei ei- 
ne Klasse keinen^ einen oder mehrere einfachen Parameter 
hat. Fur jeden Parameter werden eine interne Kennung und 
mindestens ein nach aufien sichtbarer Name^ die MeBein- 
heit (z. B. mm), ein elementarer Datentyp (z- B. ganze 
Zahl), ein voreingestellter Wert (default value) , 
Zugrif f sinformationen, ein Wertebereich und Erlauterun- 
gen abgespeichert , 

- welche komplexen Parameter die Klasse besitzt, wobei ei- 
ne Klasse keinen, einen oder mehrere komplexen Parameter 
hat. Ein komplexer Parameter verweist auf einen Typ kom- 
plexer Parameter, das ist ein benutzerdef inierter Daten- 
typ, und umfalit interne Kennung, Namen und voreinge- 
stellte Werte, 

- welche Methoden die Klasse besitzt, wobei eine Klasse 
keine, eine oder mehrere Methoden besitzt. Jede Methode 
ist durch interne Kennung, Namen, Liste der Argumente 
(mit Argument-Name und Datentyp) , Typ des Ruckgabewert 
(return type) und Methodenrumpf (body) gekennzeichnet , 

- welche Abhangigkeiten die Klasse besitzt, wobei die Ab- 
hangigkeiten als automatisch auswertbare Vorschriften 
formuliert werden, 

- Verwaltungs-Informationen, z. B-- Festlegungeji, wer Lese- 
und wer Schreibzugrif f auf die Klasse hat, wer wann die 
Klasse angelegt hat, wer sie wann zuletzt verandert hat, 
welche Anwendungen 200 lesend auf die Klasse zugegriffen 
haben . 

- Falls die Klasse ein Relations-Typ ist: ein Verweis auf 
die zugeordnete Relations-Typ-Kategorie 

- Falls die Klasse ein Relations-Typ ist: die dem Relati- 
ons-Typ zugeordneten Partner (Datenobjekt-Typen und/oder 
andere Relations-Typen) 

- Externe Verweise auf UDF-Dateien, also Dateien mit be- 
nutzerdef inierten Konstruktions-Gestaltungselementen (u- 
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ser-def ined features) fur ein bestimmtes CAD-Werkzeug^ 
abgespeichert in einem fur das Werkzeug spezifischen Da- 
tenf ormat . 

• Die Festlegungen aber die dem Relations--Typ zugeordneten 
Partner haben vorzugsweise folgende Struktur: 

- Wie viele Partner sind Datenobjekt-Typen, wie viele an- 
dere Relations-Typen? 

- die internen Kennungen der Partner,. 

- die Richtung^ in der jeder Partner an der Relation be- 
teiligt ist (z. B. Eingang, Ausgang Oder richtungslos) , 

- die fremden Rollen^ die die Partner bezuglich der Rela- 
tion spielen, 

- die eigenen Rollen, die die Relation beztiglich der Part- 
ner spielt, 

- und die Mitgliedschafts-Intervalle (Kardinalitaten) der 
Partner. 

Eine automatisch auswertbare Vorschrift kann als Parameter o- 
der als Methode eines Relations-Typs oder einer Relations- 
Typ-Kategorie realisiert sein. 

Die Syntax fur das Instanzenmodell legt folgendes fest: 

• Auf oberster Ebene umfaJJt das Instanzenmodell mindestens 
eine Instanz^ also eine Relation oder ein Datenobjekt, au- 
Berdem bei Bedarf eine Festlegung^ welche Version des In- 
stanzenmodells verwendet wird. Das Instanzenmodell kann 
beliebig viele Instanzen umfassen. 

• Fur eine Instanz werden folgende Inf ormationen festgelegt: 

- Ob die Instanz eine Relation oder ein Datenobjekt ist, 

- einen Verweis auf den Relations-Typ bzw. Datenobjekt- 
Typ, dem die Instanz angehort, und zwar vorzugsweise 
durch Angabe der internen Kennung des Typs, 
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eine interne Kennung sowie mindestens einen nach auJien 
sichtbaren Namen der Instanz - vorzugsweise wird ein Na- 
, me pro verwendete naturliche Sprache abgespeichert , 

- welche einfachen Parameter die Instanz besitzt, 
5 - welche komplexen Parameter die Instanz besitzt, 

- Verwaltungs-Inf ormationen, 

- die Rollen^ die die beteiligten Partner spielen, vor- 
zugsweise als Vektor mit einzelnen Rollen und Verweisen 
auf die Partner-Instanzen realisiert, und 

10 - die Mitgliedschafts-Intervalle ftir die beteiligten Part- 

ner. 

Beispielsweise wird ein Datensatz pro Datenobjekt-Typ 500 ge- 
maB dem Klassenmodell angelegt. Fur einen Relations-Typ 
600.1^ der n andere Typen verbindet, werden n+1 Datensatze 
15 angelegt, namlich einen ftir den Relations-Typ 600.1 selber 
und je einen fur einen Verweis auf einen Partner, d. h. einen 
Datenobjekt-Typ 500, a oder auf einen anderen Relations-Typ 
600. a, der dem Relations-Typ 600.1 zugeordnet ist und durch 
600-1 mit anderen Typen verbunden wird. 

20 Vorzugsweise wird die relationale Datenbank in Normalform 
strukturiert, jede Tabelle realisiert 1:1- und l:n- 
Verkntipfungen, aber keine m:n-Verknupfungen mit m > 1 und 
n > 1. Die internen Kennungen der Typen fungieren als Schlus- 
sel der Datensatze. Die XML-Anweisungen zur Representation 

25 der Parameter und Methoden eines Typs werden als Text in eine 
einzige Zelle des Datensatzes eingetragen. Eine XML-Anweisung 
fur einen Verweis auf einen anderen Typ wird ebenfalls in ei- 
ne einzige Zelle eingetragen. Diese Ausf uhrungsf orm hat u. a. 
den Vorteil, dali Inf ormationen schnell aus der zentralen Da- 

30 tenbank 100 eingelesen werden konnen und daB das Datenbank- 
Schema auch bei Anderung eines Datenmodells, z- B. des mit- 
tels '^XML Schema Definitions^ (XSD) realisierten Klassenmo- 
dells, nicht geandert zu werden braucht. 
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Beim Einlesen der Relations-Typ-Kategorien, Relations-Typen 
und Datenobjekt-Typen aus der zentralen Datenbank 100 warden 
die Verknupfungen zwischen Kategorien und Typen in Form von 
doppelt verzeigerten Listen im Arbeitsspeicher (random access 
memory) der Datenverarbeitungsanlage verfiigbar gehalten. Das 
zentrale Diensteprogramm 98 erzeugt diese Listen im Arbeits- 
speicher. Falls eine Anwendung 200 Inf ormationen iiber eine 
Kategorie oder einen Typ benotigt, z. B. die Taxonomie unter 
Relations-Typ-Kategorien^ so ist kein erneuter Lesezugriff 
auf die zentrale Datenbank 100 erf orderlich. Vielmehr wird 
die ben5tigte Information mit Hilfe von Verweisen (pointer) 
auf bestimmte Speicherzellen des Arbeitsspeichers beschafft. 
Diese Aus fuhrungs form spart Rechenzeit ein^ weil Zugriffe auf 
permanente Speichermedien mehr ZeitbenStigen als solche auf 
ein temporSres Speichermedium wie einen Arbeitsspeicher. 



Bezugszeichenliste 
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Bedeutung 


10 


Erf indungsgemSBes System 


50 


Benutzeroberf lache des erf indungsgemSfien 
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60 


Inferenzmaschine 


98 


Zentrales Diensteprogramm 


100 


Zentrale Datenbank 


110.1, 110.2, ... 


Lokale Datenhaltungen der Anwendungen 


150.1, 150.2, ... 


Produkt- Oder ProzeBmodelle der Anwendungen 


200.1, 200.2, ... 


Anwendungen 


250.1, 250.2, ... 


Inf ormationsweiterleitungs-Schnittstellen 


300.1, 300.2, ... 


Datenob j ekte 


400.1, 400.2 


Relationen 


500.1, 500.2, ... 


Datenob j ekt-Typen 
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600.1, 600.2, ♦.. 



Relations-Typen 
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Patentanspruche 



1. System (10) zur Erzeugung von Inf ormationen uber Datenob- 
jekte^ 

wobei ein Datenobjekt einen Bestandteil eines technischen 
Produkts Oder einen Schritt eines Entstehungsprozesses 
ftir das Produkt reprasentiert , 

und das System (10) 

- sine Einrichtung zur Erzeugung von Typen (500.1, 
500.2,. -..) von Datenobjekten (300.1, 300.2, -.-) 

- und eine Einrichtung zur Erzeugung von automatisch 
auswertbaren Vorschrif ten, deren Auswertung typisierte 
Datenobjekte (300.1, 300.2, ..-) .in Abhangigkeit von 
anderen typisierten Datenobjekten (300.1, 300.2, ...) 
ermittelt, generiert und/oder verandert, 

umf aJit , 

dadurch gekennzeichnet, 
daiJ das System (10) zusStzlich 

- eine Einrichtung zur Erzeugung von Typen (600.1, 
600. 2v ...) von Relationen (400.1, 400.2, ...) zwi- 
schen Datenobjekten (300.1, 300.2, ...)f 
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- eine Einrichtung zur Zuordnung von Datenobjekt-Typen 
(500.1^ 500.2, ...) zu einem Relations-Typ (600.1, 
600.2, ), 

- und eine Einrichtung zur Zuordnung von automatisch 
auswertbaren Vorschriften zu Relations-Typen (600.1, 
600.2, ...) 

umf aBt 



System nach Anspruch 1, 

dadurch gekennzeichnet, 
dalJ das System (10) 

- eine Einrichtung zur Erzeugung von Kategorien von Re- 
lations-Typen (600-1, 600.2, .-.) 

- und eine Einrichtung zur Erzeugung einer Taxonomie un- 
ter Relations-Typ-Kategorien 

umf aBt 

und die Einrichtung zur Erzeugung von Relations-Typen so 
ausgestaltet ist, 

daB mit ihr ein Relations-Typ (600.1, 600.2, ..Or der zu 
einer vorgegebenen Kategorie gehort, erzeugbar ist. 



3. System nach Anspruch 2, 

dadurch gekennzeichnet, 
dafi das System (10) 

- einen ersten Inf ormationsspeicher mit einer ersten an- 
wendungsiibergreif enden erweiterbaren Standard- 
Bibliothek mit Datenobjekt-Typen (500.1, 500.2, 
... )und Relations-Typen (600.1, 600.2, ...), 

einen zweiten Inf ormationsspeicher mit einer zweiten 
anwendungsiibergreif enden erweiterbaren Standard- 
Bibliothek mit Relations-Typ-Kategorien 
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- und eine Einrichtung zur Erzeugung einer Relations- 
Typ-Kategorie als Unterkategorie einer Relations-Typ- 
Kategorie der zweiten Standard-Bibliothek 

xjmf alSt . 



System nach Anspruch 2 oder Anspruch 3, 
dadurch gekennzeichnet^ 
dais das System (10) 

- einen ersten Datenspeicher ftir Relations-Typ- 
Kategorien, 

- einen zweiten Datenspeicher fiir Datenobjekt-Typen 
(500.1, 500-2, ...) und Relations-Typen (600.1, 600-2, 
...) 

- und einen dritten Datenspeicher fUr typisierte Relati- 
onen (400.1, 400.2, ...) 

umf afit . 



5, System nach Anspruch 4, 

dadurch gekennzeichnet, 

dali das System (10) eine relationale Datenbank fur die 
drei Datenspeicher umfaBt 

und ein Datensatz dieser Datenbank fur eine Relations- 
Typ-Kategorie, einen Datenobjekt-Typ (500.1, 500.2, ...)r 
einen Relations-Typ (600.1, 600.2, ...) oder eine Relati- 
on (400.1, 400.2, . . •) 

eine Zelle fur eine eindeutige Kennung und mindestens ei- 
ne Zelle ftir Inf ormationen, die im Datenformat XML struk- 
turiert sind, umfalSt- 

6. System nach einem der Anspruche 1 bis 5, 
dadurch gekennzeichnet. 
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dali das System (10) eine Einrichtung zur Zuordnung eines 
Relations-Typs (600.1^ 600.2^ ...) zu einem anderen Rela- 
tions-Typ (600.1, 600.2, ...) umfalit. 

7. System nach einem der Anspruche 1 bis 6, 
dadurch gekennzeichnet, 

daJi das System (10) eine Einrichtung zur Erzeugung einer 
Relation (400.1, 400.2, ..-)f die von einem vorgegebenen 
Relations-Typ (600.1, 600.2, ...) ist, umfafit. 

8. System (10) zur Erzeugung von Informationen uber Datenob- 
jekte (300.1, 300.2, ...), 

wobei ein Datenobjekt (300.1, 300.2, ...) einen Bestand- 
teil eines technischen Produkts oder einen Schritt eines 
Entstehungsprozesses fur das Produkt reprasentiert, 

und das System (10) 

- eine Einrichtung zur Erzeugung von Typen (500.1, 
500.2, ...) von Datenobjekten (300.1, 300.2, -..) 

- und eine Einrichtung zur Erzeugung von automatisch 
auswertbaren Vorschriften, deren Auswertung typisierte 
Datenobjekte (300.1, 300.2, ...) in AbhSngigkeit von 
anderen typisierten Datenobjekten (300.1, 300.2, ...) 
ermittelt, generiert und/oder verSndert, 

umf aBt, 

dadurch gekennzeichnet, 
daJi das System (10) 

- eine Einrichtung zur Zuordnung eines Datenobjekt-Typs 
(500.1, 500.2, ...) zu mindestens einer von mindestens 
zwei verschiedenen Phasen des Entstehungsprozesses 

- und eine Einrichtung zur Erzeugung einer einzigen Ta- 
xonomie 
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- far Datenobjekt-Typen (500.1^ 500.2, die einer 
ersten Phase zugeordnet sind, 

- und fur Datenobjekt-Typen (500,1, 500. 2, die 
einer zweiten Phase zugeordnet sind 

umf afit . 



9. System nach einem der Anspruche 1 bis 8, 
dadurch gekennzeichnet, 

daB die Einrichtung zur Zuordnung von Datenobjekt-Typen 

die Zuordnung von jeweils mindestens zwei der folgenden 
Datenobjekt-Typen (500.1, 500,2, ...) zu einem Relations- 
Typ (600.1, 600.2, ...) ermoglicht: 

- Typen von Konstruktions-Gestaltungselementen, 

- Typen von Bauteilen, 

- Typen von Zusammenbauten, 

- Typen von Fertigungs-Gestaltuhgselementen, 

- Typen von Qualitats-Gestaltungselementen, 

- Typen von Mel5-Gestaltungselementen, 

- Typen von PrUf-Gestaltungseleitienten, 

- Typen von Werkstoffen, 

- Typen von Fertigungs-Vorrichtungen, 

- Typen von Betriebsmitteln 

- und Typen von Kommentaren. 

10. System nach einem der Anspruche 1 bis 9, 

dadurch gekennzeichnet, 

daft das System (10) eine Inf ormationsweiterleitungs- 
Schnittstelle (250.1, 250.2, ...) zu einer Datenverarbei- 
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tungseinrichtung zum Erzeugen und Bearbeiten eines Mo- 
dells (ISO^l, 150.2^ ...) 

- des Produkts oder eines Teils des Produkts, 

- eines Herstellungsprozesses zur Fertigung des Produkts 
Oder eines Teils des Herstellungsprozesses, 

- eines Arbeitsablauf s oder eines Teils eines Arbeitsab- 
lauf s, 

- Oder der Kosten zur Herstellung des Produkts 
umf alJt . 

11. System nach Anspruch 10, 

dadurch gekennzeichnet, 

dafi die Inf ormationsweiterleitungs-Schnittstelle (250.1, 
250.2, •--) so ausgestaltet ist, 

dafi iiber diese der Typ, eine Kennung und bei Bedarf Me- 
thoden und/oder Attributwerte eines von der Datenverar- 
beitungseinrichtung zu erzeugenden Datenobjekts (300.1, 
300.2, ...) libeimittelt werden kSnnen. 

12. System nach Anspruch 10 oder Anspruch 11, 
dadurch gekennzeichnet^ 
dafi 

das System (10) eine Einrichtung zur Erzeugung eines Be- 
nutzerprof ils eines Benutzers umfafit, 

wobei das Benutzerprof il mindestens eine der folgenden 
Festlegungen umfafit : 

- Lese- und Schreibberechtigungen des Benutzers, 

- Fahigkeiten des Benutzers beim Erzeugen und Bearbeiten 
von Datenobjekten (300.1, 300.2, 
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- Vorlieben des Benutzers beim Erzeugen und Bearbeiten 
von Datenobjekten (300.1, 300.2, .--) 

und die Inf ormationsweiterleitungs-Schnittstelle (250.1, 
250.2, ...) so ausgestaltet ist, 

dafi Festlegungen des Benutzerprof ils uber die Schnitt- 
stelle (250.1, 250.2, ...) ubermittelt werden k5nnen. 

13. Informationsmodell ftir Datenobjekte (300.1, 300.2, ...), 

die jeweils einen Bestandteil eines technischen Produkts 
Oder einen Schritt eines Entstehungsprozesses ftir das 
Produkt reprasentieren, 

wobei das Informationsmodell 

- Typen (500.1, 500.2, ...) von Datenobjekten (300-1, 
300.2, ...) 

- und automatisch auswertbare Vorschrif ten, ' deren Aus- 
wertung Datenobjekte (300.1, 300.2^ ...) in Abhangig- 
keit von anderen Datenobjekten (300.1, 300.2, ...) ge- 
neriert oder verandert. 



dafi 

- das Informationsmodell Typen (600.1, 600.2, ...) von 
Relationen (400.1, 400.2, ...) zwischen Datenobjekten 

• (300.1, 300.2, ...) xamfaJit, 

- einem Relations-Typ (600.1, 600.2, ...) eine automa- 
tisch auswertbare Vorschrift zuordenbar ist 

- und einem Relations-Typ (600.1, 600.2, ...) 

- mindestens zwei Datenobjekt-Typen (500.1, 500.2, 
. . .) - 

- Oder mindestens ein Datenobjekt-Typ (500.1, 500.2, 
. . . ) und mindestens ein anderer Relations-Typ 
(600.1, 600.2, ...) 



umf afit , 



d a d u r c h 



gekennzeichnet. 



P801402/DE/2 



m 



m 



Oder mindestens zwei andere Relations-Typen (600.1, 
600.2, . . . ) 



zugeordnet sind. 



14. Inf ormationsmodell nach Anspruch 13, 



d a d u r c h 



gekennzeichnet. 



daB das Inf ormationsmodell 

- Kategorien von Relations-Typeii (600.1, 600.2, ...) 

- und eine Taxonomie unter Relations-Typ-Kategorien 
umf alit 

und ein Relations-Typ (600.1, 600.2, ...) einer Relati- 
ons-Typ-Kategorie zuordenbar ist. 

15. Inf ormationsmodell nach Anspruch 13 oder Anspruch 14, 

dadurch gekennzeichnet, 

daB mindestens einem Relations-Typ (600.1, 600.2, ...) 
Mitgliedschafts-Intervalle und/oder Rollen 

fiir die Datenobjekte (300 . 1, 300.2, .•-) und/oder Relati- 
onen (400.1, 400.2, ...), die duirch eine Relation des Re- 
lations-Typs (600.1, 600.2, .) verbunden werden, zuge- 
ordnet sind. 

16. Informationsmodell nach einem de'r Ansprtlche 13 bis 15, 

dadurch gekennzeichnet, 

daB das Informationsmodell Phasen-Datenobjekte (300.1, 
300.2, ...), die jeweils eine Phase des Entstehungspro- 
zesses reprasentieren, umfafit . 

und einem Datenobjekt-Typ (50011, 500.2, .-.) ein Phasen- 
Datenobjekt (300.1, 300.2, . . - ) zuordenbar ist. 
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17. Informationsmodell nach einem der Anspruche 13 bis 16, 

dadurch gekennzeichnet, 

daii das Informationsmodell ein Datenmodell ftlr die dauer- 
hafte Speicherung von Datenobjekt-Typen (500. 1^ 500.2^ 
...) und/oder Relations-Typen (600.1^ 600.2, ...)/ die 
gemSB dem Informationsmodell strukturiert sind, lomfaBt. 
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Zusammenf assun g 




5 Die Erfindung betrifft ein System (10) zur Erzeugung und 
Speicherung von Datenobjekten (300.1, 300.2, die je- 

weils einen Bestandteil eines technischen Produkts oder einen 
Schritt eines Entstehungsprozesses fur das Produkt reprasen- 
tieren. Erf indungsgemali vermag das System (10) Typen von Re- 
10 lationen (600.1, 600.2, -..) zwischen mehreren Datenobjekt- 
Typen (500.1, 500.2, ...) zu erzeugen und diesen Typen Daten- 
objekt-Typen (500.1, 500.2, ...) sowie automatisch auswertba- 
re Vorschriften fur Abhangigkeiten zwischen Datenobjekten 
_ (300.1, *300. 2, ...) zuzuordnen. Vorzugsweise ist eine. Taxono- 

^^H.5 mie ftir Datenobjekt-Typen (500.1, 500.2, ...) verschiedener 
^^^^ Phasen des Entstehungsprozesses vorgesehen. Die Erfindung er- 
mOglicht es, verschiedene Anwendungen (200.1, 200.2, ...) ftir 
jeweils bestimmte Phasen miteinander zu koppeln,. ohne ein 
Zwischenmodell oder direkte Schnittstellen zwischen den An- 
20 wendungen erzeugen und pflegen zu mUssen. 

(Fig. 1) 
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